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