Redakcja
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:
- 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..
- 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.
- 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.
- 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).
- 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.
- 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.
- 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).
- 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).
- 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.
- Regularnie tworzymy kopie zapasowe repozytorium (dump).
- 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
