Narzędzia używane w Droptica - cz. III

Starając się, żeby drupalowe usługi były na najwyższym poziomie, wykorzystujemy różne narzędzie, które usprawniają naszą pracę. Czas na kolejną porcję informacji o tym, co robimy, aby zadania realizować najefektywniej. Dzisiaj będzie o wersjonowaniu plików oraz o testowaniu aplikacji.

Subversion

Początkowe projekty realizowane na Drupalu (jeszcze jako OPENBIT) używały systemu Subversion (znany również jako SVN, strona projektu) do wersjonowania plików. Jednym z takich projektów był system intranetowy dla firmy Telefonia Dialog S.A. (case study).

SVN, jak inne systemy wersjonowania, pozwala na trzymanie historii zmian plików. Główną różnicą między SVN a GIT (o nim za chwilę) jest to, że w SVN repozytorium jest trzymane na jednym zdalnym serwerze, do którego wszyscy wprowadzają zmiany. Wymusza to commitowanie tylko do zdalnego serwera, nie można commitować tylko lokalnie nieskończonych zmian. Z SVN pojawiały się czasem trudne do rozwiązania konflikty (na przykład, gdy dwie osoby pracowały na tych samych plikach). Niewygodne było także zarządzanie branchami i ich łączenie.

GIT

W 2012 roku rozpoczęliśmy pierwsze próby z użyciem GIT-a na projektach. Pierwszą "dziwną" rzeczą było to, że aby wysłać zmiany na serwer, nie wystarczyła komenda "commit", potrzebna była dodatkowa komenda "push". Tego dodatkowego kroku nie było w SVN. Wynika to z tego, że GIT jest systemem rozproszonym, czyli repozytorium nie jest trzymane na jednym serwerze, ale w wielu miejscach (np. na komputerach programistów, serwerach testowych itp).

W GIT commitujemy do repozytorium, które mamy lokalnie na komputerze, a następnie synchronizujemy nasze zmiany (commity) z innym repozytorium. Z reguły ustala się jedno zdalne repozytorium jako to główne miejsce na wypychanie zmian. Nie ma jednak żadnych przeszkód, aby jeden programista wypchał swoje zmiany do repozytorium na komputerze drugiego programisty (potrzebny dostęp np. przez SSH), drugi programista kończy zadanie i dopiero wypycha zmiany na zdalny główny serwer.

GIT bardzo dobrze radzi sobie z łączeniem zmian wprowadzanych w tym samym pliku. Wygodne też jest łączenie gałęzi (branchy) w repozytorium. Przez bardzo wielu użytkowników GIT jest uważany za bardzo dobry system wersjonowania i my się z tą opinią w pełni zgadzamy.

GIT GUI

GIT jest aplikacją konsolową, czyli aby go używać, należy wprowadzać komendy w terminalu. Dla początkujących użytkowników może być to trudne, dlatego na początek polecamy użycie graficznej nakładki na GIT. Kilka przykładów takich programów poniżej:

• Smartgit (Linux, Windows, MacOS), program płatny, ale ma dużo opcji i przejrzysty interfejs. Część osób w Droptica używa tego programu.
• GitKraken (Linux, Windows, MacOS)
• GitEye
• Giggle

Jest jeszcze wiele innych programów tego typu, wystarczy wpisać w Google: GIT GUI. Nie wszystkie jednak działają na Linux, Windows i MacOS jednocześnie.

Git-flow

W GIT możemy tworzyć branche (gałęzie). Dzięki branchom możliwa jest praca nad zadaniem obok głównego sprawdzonego już kodu. W skrócie praca wygląda tak:

• rozpoczynamy prace nad nowym zadaniem programistycznym
• tworzymy nowy branch
• wykonujemy zadanie w branchu
• testujemy zadanie w branchu
• po przejściu testów i code review branch jest dołączany (merge) do głównego brancha

Takie operowanie na branchach wymaga kilku powtarzających się komend. Aby to usprawnić,  powstał Git-flow, czyli rozszerzenie do GITa dodające nowe komendy. Dokładny opis modelu tworzenia branchy używanego przez Git-flow znajdziecie na stronie http://nvie.com/posts/a-successful-git-branching-model/

W Droptica używamy git-flow i bardzo chwalimy to podejście. Pozwala nam to na eliminację błędów w realizowanych zadaniach przed dołączeniem kodu do głównej gałęzi. W ten sposób mamy zapewnione, że branch developerski ma tylko przetestowane kody.

Github

Większość kodów projektów trzymamy w prywatnych repozytoriach w serwisie GitHub.com. Używamy Githuba, ponieważ zapewnia stabilne serwery do przechowywania plików oraz oferuje opcję “Pull request”.

Pull request jest to żądanie połączenia jednego brancha do drugiego, np. połączenie brancha jednego programisty do głównego brancha aplikacji. W czasie tworzenia pull request możemy zobaczyć podsumowanie zmian pomiędzy dwoma branchami. Jeśli programista w swoim branchu zrobił kilka commitów, to wszystkie commity zostaną “połączone” w jedną zmianę. Zobaczymy wtedy przejrzyste porównanie zmian w kodzie, jakie zostaną wykonane po akceptacji pull request (zostanie wykonana operacja merge).
 

Taki podgląd pozwala na bardzo łatwy przegląd kodu. W ten sposób główny programista na projekcie może szybko zweryfikować, czy zmiany innego programisty są poprawne i możliwe do zmergowania. Przegląd kodu w pull request przez drugą osobę gwarantuje nam to, że kod w aplikacji znają zawsze minimum dwie osoby.

Jeśli chcesz więcej dowiedzieć się o Git to koniecznie przeczytaj książkę “Pro Git”. Książka jest dostępna w wersji cyfrowej tutaj. Możesz również zamówić książkę w wersji
papierowej. 

W naszej agencji drupalowej przy tworzeniu serwisów internetowych, zarówno w Drupalu jak i w innych technologiach, nie wyobrażamy sobie już pracy bez Gita.