Systemy kontroli wersji – dobre praktyki

Systemy kontroli wersji – dobre praktyki
Niezależnie od tego z jakiego systemu wersjonowania plików korzystamy (SVN, GIT, CVS)  jest kilka podstawowych zasad, których powinniśmy się trzymać, aby wersjonowanie plików miało sens.


Dobre praktyki:

  1. Wersjonujemy wszystko – kod aplikacji, dokumentację techniczną, instrukcje użytkownika i administratora, dokumentację bazy danych, dokumentację projektową (mockupsy, use case`y, diagramy BPMN). Dzięki temu każdy uczestnik projektu będzie miał do nich dostęp i unikniemy sytuacji w której z jakiegoś powodu stracimy efekt kilku(nastu) godzin naszej pracy. Zdarzyło mi się kiedyś tworzyć dokumentację przez 2 dni po czym błąd aplikacji w której pracowałem spowodował tak głębokie uszkodzenie pliku, że nie było mowy o jego odzyskaniu. 2 dni pracy w plecy..
  2. Utrzymujemy wspólną konwencje struktury wszystkich repozytoriów, tak aby zespół włączając się do innego projektu nie musiał poznawać tej struktury od nowa. Mam na myśli podział na trunk, branches i tags oraz strukturę wewnątrz nich. Przykładowo: w każdym repozytorium umieszczamy folder „Docs” w którym przechowujemy całą dokumentację powykonawczą projektu, lub folder „Concept” gdzie przechowujemy wszystkie opisy wymagań i dokumentację służącą do wytworzenia aplikacji.
  3. Określamy listę plików, których nie commitujemy – możemy to zrobić na dwa sposoby: przez ustalenie zasad pracy z SVN i przekazanie jej zespołom programistycznym albo przez commit hook blokujący określone pliki. Mam tu na myśli np. pliki projektowe IDE.
  4. Commit-ujemy niewiele, ale często – jeden commit = jedno zgłoszenie z bugtrackera, jedna nowa funkcjonalność lub jedno zadanie. Dzięki temu łatwiej jest rozwiązywać konflikty oraz dokonywać złączeń (merge).
  5. Zawsze umieszczamy komentarz do commit-a (podobnie jak w punkcie 3, możemy to wymusić pre commit hookiem). W komentarzu wpisujemy numer zgłoszenia/zadania oraz jego krótki opis. Dzięki temu za pół roku będziemy mogli wiedzieć co kto robił, oraz jakie pliki dotyczą konkretnych funkcjonalności czy modyfikacji. Dodatkowo, jeżeli mamy zintegrowany SVN z Mantisem, możemy automatycznie zamykać zgłoszenia w Mantisie poprzez umieszczanie odpowiednich fraz w komentarzu do commita, po czym ten komentarz zostanie umieszczony w rozwiązaniu zgłoszenia.
  6. Zawsze commit-ujemy zakończoną funkcjonalność / zmianę – nawet jeżeli koliduje to z zasadą nr 4. Dzięki temu wiemy, że wszystkie pliki zmienione w danej rewizji dotyczą tego samego zagadnienia.
  7. Jeżeli wprowadzamy istotne modyfikacje wymagające np. aktualizacji bazy danych lub wglądu w dokumentację techniczną informujmy mailowo osoby zainteresowane. Możemy to rozwiązać odpowiednim hookiem commitowym (wysyłającym email lub publikujący wpis na tweeterze).
  8. Regularnie aktualizujemy kopię roboczą do Head Revision. Zawsze przed rozpoczęciem pracy i przed commitem. Nie dopuszczamy do „rozjechania się” kopii roboczej z repozytorium (np. przez sytuację, w której kilkukrotnie commit-owaliśmy po kilka plików, a po pewnym czasie okazuje się, że 10 plików różni się od wersji z serwera, a my nie wiemy dlaczego).
  9. Tagujemy wydania stabilne oraz wszystkie rewizje przed poleceniem Merge. W zależności od tego jaką mamy przyjętą politykę (np. trunk zawsze stabilny). Dodatkowo ustalamy politykę tworzenia gałęzi.
  10. Regularnie tworzymy kopie zapasowe repozytorium (dump).
  11. Nigdy nie modyfikujemy plików bezpośrednio na serwerze. Pomimo tego, że SVN dopuszcza modyfikację komentarzy (trzyma to w plikach tekstowych) nie powinniśmy tego robić. Istnieje duże ryzyko uszkodzenia repozytorium.



Autor: Cezary Kamiński
Artykuł (po kosmetycznych zmianach) pochodzi z blogu IT Managament - Zarządzanie Projektami IT: cezarykaminski.pl

 

11038

Powiązane szkolenia

05-06
czerwca
2023
Jarosław Hryszko
online
Praktyka testowania
1 750PLN
Testowanie aplikacji internetowych
12
Wolnych miejsc
Rezerwuj
06-07
marca
2023
Arnika Hryszko
online
Praktyka testowania
1 770PLN
Testowanie użyteczności
9
Wolnych miejsc
Rezerwuj
20-21
kwietnia
2023
Rafał Stańczak
online
Dobre praktyki testowania
1 700PLN
Testowanie w metodykach Agile
12
Wolnych miejsc
Rezerwuj
23-24
marca
2023
Krzysztof Kołodziejczyk
online
Praktyka testowania
1 770PLN
Testowanie aplikacji mobilnych - Android
9
Wolnych miejsc
Rezerwuj
12-13
czerwca
2023
Krzysztof Skarbiński
online
Automatyzacja testowania
1 800PLN
Testowanie REST API dla początkujących w języku python
11
Wolnych miejsc
Rezerwuj
27-28
lutego
2023
Krzysztof Kołodziejczyk
online
Języki programowania dla testerów
1 800PLN
JavaScript dla testerów oprogramowania
10
Wolnych miejsc
Rezerwuj
10-12
kwietnia
2023
Krzysztof Kołodziejczyk
online
Praktyka testowania
3 000PLN
Tester gier
11
Wolnych miejsc
Rezerwuj
13
marca
2023
-09
kwietnia
2023
Krzysztof Kołodziejczyk
online
Automatyzacja testowania
5 500PLN
Praktyka automatyzacji testowania
5
Wolnych miejsc
Rezerwuj

To powinno Cię zainteresować