W prezentacji przedstawione zostaną nowe narzędzia i sposoby ich wykorzystania w efektywnym zarządzaniu zadaniami. Pod każdym slajdem zamieszczony został komentarz. Poruszając się po prezentacji poziomo (< >) oglądamy kolejne slajdy. Pionowa nawigacja (^ v) przełącza między slajdem a komentarzem.

Bezpośrednią konsekwencją wprowadzenia GITa była konieczność znalezienia narzędzi umożliwiających zarządzanie repozytorium. Najciekawszym z naszego punktu widzenia okazał się Atlassian Bitbucket Server.

Bitbucket pozwala na tworzenie nowych repozytoriów GIT i zarządzanie nimi w podobny sposób jak np. GitHub. Oprócz przeglądania kodu, kolejnych zmian, podglądania gałęzi, mamy tu również kompletnych mechanizm Pull Request, a także bardzo podstawowe narzędzia do Code Review z systemem komentarzy. Jest też oczywiście uwierzytelnianie i zarządzanie dostępem dla grup użytkowników.

Jednak najważniejszym atutem tego rozwiązania okazała się bardzo dobrze zrealizowana integracja z innymi systemami Atlassiana, których używamy. W ten sposób zainstalowanie Bitbucketa otworzyło przed nami szereg nowych możliwości, o których powiemy w dalszej części prezentacji.

• Ograniczenie bezpośrednich zmian w gałęzi develop
• Zabezpieczenie przed edycją wybranych fragmentów repozytorium
• Kontrola zmian sugerowanych przez inne zespoły
• Ustalanie warunków akceptacji Pull Request (pomyślne Code Review, zielone Bamboo)

Mechanizm Pull Request w znaczny sposób ułatwia kontrolę nad wprowadzaniem zmian do głównej gałęzi projektu. Każdy Feature przed scaleniem z Developem musi zostać zgłoszony na Bitbuckecie jako Pull Request. Pull Request musi zostać zatwierdzony (najczęściej przez osobę, która robi review) i dopiero wtedy może zostać scalony. Co istotne, istnieje możliwość scalenia zmian bezpośrednio z poziomu strony Pull Requesta na Bitbuckecie.

Dodatkowo, można wymusić dodatkowe warunki akceptacji Pull Requesta, kontrolowane przez Bitbucketa: poprawienie wszystkich uwag oznaczonych w review, pomyślne rezultaty odpalenia testów na Bamboo.

Podczas pracy z GIT najczęściej korzysta się z konsoli. My jednak chcieliśmy by sposób korzystania z systemu kontroli wersji był jak najprostszy (duży projekt + duże możliwości GITa = łatwo o tragiczny w skutkach wypadek). Istnieje niewiele klientów GUI dla GITa, a jeszcze mniej nadaje się do użytku. SourceTree wydaje się obecnie najlepszym tego typu programem. Zapewnia wsparcie dla wszystkich typowych operacji i działa stabilnie. Poza tym jest to również produkt Atlassiana, dzięki czemu można np. sklonować repozytorium jednym kliknięciem na Bitbuckecie.

Dołożenie do stosu technologicznego Bitbucketa (i potencjalnie SourceTree) spowodowało, że dysponujemy obecnie czterema systemami Atlassiana: Jira, Bitbucket, Bamboo i Confluence. Jak się okazało, istnieje możliwość skonfigurowania tych serwisów w taki sposób by współpracowały ze sobą.

Jira (jako centrum zarządzania zadaniami) pozwala obserwować gałęzie podpięte do danego zadania na Bitbuckecie, a także powiązane z nimi stany buildów na Bamboo, a nawet dokumenty na Confluence.

Bitbucket może automatycznie zmieniać status zadania na Jirze na bazie akcji, związanych z obsługą Pull Requesta.

Bamboo może blokować możliwość akceptacji Pull Requesta, dopóki nie zostaną spełnione określone warunki związane z danym planem.

Confluence potrafi łączyć swoje strony z odpowiednimi zadaniami na Jirze, co zapobiega redundantnym oznaczeniom i pozwala łatwo odnaleźć się w projekcie.

Jednym z głównych narzędzi integracji między serwisami Atlassiana jest Issue Linking. Każde zadanie na Jirze może definiować powiązanie z innym zadaniem, stroną na Confluence (lub nawet dowolną inną stroną w sieci). Powiązania działają w dwie strony i mogą być nazywane przez użytkownika.

Bitbucket swoje powiązania realizuje w oparciu o tagi z nazwą kodową zadania. Aby dany commit został prawidłowo przypisany do zadania (i był tym samym widoczny na Jirze), musi zawierać w swojej wiadomości nazwę kodową issue. Przygotowana przez nas konfiguracja wymusza używanie poprawnych tagów, odrzucając commity z niepoprawnie sformułowanymi wiadomościami.

Nowy workflow angażuje więcej narzędzi, ale wiele czynności ulega dzięki temu automatyzacji, upraszczając czynności wykonywane przez dewelopera:

1. Weź nowe zadanie (issue)
2. Utwórz nową gałąź na Bitbuckecie.
   Jira automatycznie zmieni status issue, a Bamboo utworzy nowy plan dla gałęzi.
3. Wykonaj checkout gałęzi w SourceTree
4. Zaimplementuj swoje rozwiązanie.
   W każdej chwili możesz uruchomić zdalnie testy na Bamboo, które wykonają się w tle.
5. Utwórz Pull Request na Bitbuckecie.
   Jira automatycznie zaktualizuje status issue, a Bamboo nie pozwoli wykonać Merge dopóki testy nie przejdą.
6. Poczekaj na Review. Możesz oglądnąć uwagi odnośnie kodu na Bitbuckecie. Jeśli otrzymasz Reopen, wróć do punktu 4. Jeśli wszystko będzie ok, reviewer kliknie Merge na Bitbuckecie i gałąź zostanie scalona z Developem.

Oczywiście narzędzia, których używa deweloper to kwestia jego prywatnych upodobań. Niemniej jednak, sugerujemy kilka rozwiązań, które uważamy za wygodne i godne sprawdzenia.

W przypadku SVN do rozwiązywania konfliktów używaliśmy TortoiseMerge, zintegrowanego z TortoiseSVN. Wiele osób jest do niego przyzwyczajonych, a legendarne Tęczowe Ryśki wywołują uśmiech na zmęczonych twarzach deweloperów. Nie da się jednak ukryć, że nieco agresywny sposób prezentowania konfliktów i oznaczanie całych sekcji jaskrawymi kolorami nie wszystkim się spodoba. Czytelność tego rozwiązania jest dyskusyjna...

p4Merge to "jeszcze jeden sposób na rozwiązywanie konfliktów". Program, będący oryginalnie częścią komercyjnej platformy Perforce, prezentuje się nieco mniej archaicznie niż klasyczny TortoiseMerge. Zamiast wykreślanych bloków kodu mamy tu chmurki/dymki/balony zaznaczające różnice w kodzie. Ciekawym rozwiązaniem jest zastosowanie trzech widoków zamiast dwóch. Widzimy zarówno swoje zmiany, zmiany w repozytorium, jak i pierwotną postać pliku.