Helix TeamHub wszystkie repozytoria w jednym miejscu – część 3: pierwsze kroki z Helix TeamHub

Proces instalacji Helix TeamHub Enterprise na lokalnym serwerze przebiega w sposób błyskawiczny. Nie potrzebujemy do tego żadnej dokumentacji technicznej. Za pomocą kilku poleceń nasza instancja jest gotowa do pracy. Helix TeamHub ma bardzo intuicyjny interfejs użytkownika, w którym wszystkie najważniejsze funkcje znajdują się dokładnie tam, gdzie się tego spodziewamy.

Po zalogowaniu widzimy pulpit, który pokazuje nam ogólne zestawienie naszych projektów, wszystkich użytkowników repozytoriów oraz przechowywane dane w panelu kontrolnym. Możemy również zobaczyć zgłoszenia dotyczące problemów, które aktualnie śledzimy oraz oczekujące na nas recenzje kodu.

Pics. by Kamila Izdebska

Do dyspozycji mamy dwie możliwości rozpoczęcia pracy: albo skorzystamy z przycisku szybkiej akcji, który znajduje się w prawym górnym rogu lub wybierzemy menu z głównymi funkcjami Helix TeamHub znajdujące się po lewej stronie interfejsu. Po chwili możemy przeprowadzić cały proces tworzenia projektu dodając użytkowników z którymi będziemy współpracować. Zrobimy przegląd kodu, a następnie przyjrzymy się wbudowanej Wiki, używanej w dokumentacji dla programistów oraz wbudowanej tablicy Kanban do zarządzania projektami. Tablice kanbanowe bardzo ułatwiają organizowanie i priorytetyzowanie zadań związanych z naszą pracą.

Po wyborze okna dialogowego dotyczącego nowego projektu (prawy górny róg) wpisujemy nazwę projektu. Domyślnie pojawia nam się możliwość jednoczesnego utworzenia repozytorium Wiki dla tego projektu i dodania do niej opisu. Wybieramy przycisk “Create project”. W tym momencie projekt jest gotowy.

Jeśli tworzymy nowy projekt, automatycznie stajemy się jego administratorem i możemy zapraszać do współpracy innych użytkowników, z którymi będziemy pracować. Możemy w tym celu wykorzystać przycisk szybkiej akcji (quick action menu – prawy górny róg ekranu).

Po dodaniu współpracownika mamy do wyboru kilka ról, jakie możemy mu przypisać. W rozwijanym menu do wyboru jest sześć ról (m.in. gościa, specjalisty, menedżera oraz administratora) i aż osiem poziomów dostępu do zasobów.

Po wykonaniu tych czynności pojawi się pulpit użytkownika, na którym widnieje administrator oraz współpracownicy z określonymi rolami. Możemy przystąpić do tworzenia repozytorium dla tego projektu.

W przycisku szybkiej akcji lub w menu głównym po lewej stronie wybieramy “Repositories”. Widzimy, że Wiki od początku towarzyszy naszemu projektowi. Co ciekawe, możemy mieć wiele repozytoriów w jednym projekcie! I to jest właśnie kluczowa funkcja TeamHub. Przy wyborze nowego repozytorium pojawia się nam opcja typu repozytorium. Może to być Git, Ivy, Maven, Mercurial, Subversion, WebDAV.

Na samym początku pojawia nam się krótka instrukcja postępowania z pustym repozytorium. Adres nowoutworzonego repozytorium możemy skopiować lokalnie funkcją “clone”, a następnie utworzyć kopię projektu bezpośrednio z TeamHub w terminalu na komputerze, poprzez wklejenie skopiowanego adresu URL. Po ściągnięciu mamy kopię na własnym komputerze. Jeśli repozytorium będzie puste, system wyśle nam ostrzeżenie o tym fakcie. W następnej kolejności możemy rozpocząć kodowanie w terminalu. Jeśli zaprosiliśmy jeszcze inne osoby do współpracy, to one również mogą zacząć pracę.

Po utworzeniu pierwszego pliku, dodaniu commita i wprowadzeniu zmian, możemy za pomocą standardowych komend wysłać (git push) zmodyfikowany plik z powrotem do TeamHub. Po odświeżeniu pojawi się na panelu w Master Branches wraz z podglądem treści. Będziemy mieli również listę różnych repozytoriów, jakie używamy w danym projekcie.

Po ponownym otwarciu okna dialogowego na własnym komputerze, możemy stworzyć za pomocą terminala nową gałąź oprogramowania (New Branch), a potem zlecić jej śledzenie w Helix TeamHub. Następnie analogicznie dodajemy zmieniany plik i wykonujemy pusha. Po wprowadzeniu zmian i przełączeniu się na Helix TeamHub możemy uruchomić code review.

Po utworzeniu nowego brancha, uruchamiamy śledzenie tego brancha, dodajemy plik, wykonujemy commit i push. Po powrocie do TeamHuba i odświeżeniu widoku widzimy nowy branch ze zaktualizowanymi danymi. W celu utworzenia nowego code review wybieramy z naszego szybkiego menu (w prawym górnym rogu) “new code review”. Na początku w oknie dialogowym wybieramy repozytorium, którego dotyczy nasz code review, określamy branch źródłowy i docelowy oraz wpisujemy tytuł i opis.

Poniżej opisu znajdują się dwie, bardzo ciekawe opcje. Pierwsza (Approvals) oznacza możliwość zdefiniowania właściwej liczby użytkowników, która musi akceptować ten code review, aby zaczął funkcjonować. Drugą opcja (Require passing build) dotyczy sytuacji, w której mam skonstruowany pipeline. Wtedy nasz kod zostanie wysłany do testów i dopiero, kiedy przejdzie je pomyślnie, nastąpi połączenie.

Po utworzeniu new code review otwiera nam się okno w którym mamy wszystkie niezbędne informacje. Możemy uzupełnić dodatkowo opis, dodać komentarze etc. Przechodząc do zakładki “Commits” możemy zobaczyć historię zmian w kodzie. Pokazuje się nam dwustronny podgląd różnic. Kod możemy weryfikować linia po linii, dodając w razie potrzeby komentarze do każdej z nich lub do całości naszego code review.  W lewym górnym rogu możemy zidentyfikować wszystkie powiązane pliki, a po prawej stronie znajdują się różne dostępne opcje scalania kodu. Akcję commit/merge wykonujemy za pomocą jednego szybkiego przycisku.

Wszystkie wprowadzone zmiany zostaną następnie dołączone do brancha docelowego, natomiast pierwotne źródło kodu pozostanie w niezmienionym kształcie pod nazwą własną w zakładce Branches – możemy je usunąć w razie potrzeby.

Po zakończeniu przeglądu kodu, kolejnym logicznym krokiem będzie udokumentowanie zmian, które wprowadziliśmy. Tak, jak pisaliśmy powyżej, Wiki towarzyszy naszemu projektowi od samego początku. Nie różni się ona od innych Wiki wykorzystywanych w innych narzędziach, ale ma wygodny dodatek związany z edycją. Nowy tytuł dodajemy za pomocą prostych komend. Możemy tu dodać pliki, ważne linki oraz wszystkie inne informacje potrzebne dla danego projektu.

Po otwarciu zakładki “Issues” z głównego menu rozwija nam się cała lista zgłoszeń/problemów dla danego projektu. Mamy możliwość zdefiniowana milestonów dla każdego issue osobno, nadawania priorytetów, określania zadań i przypisywania do nich konkretnych użytkowników. Filtrowanie listy może dotyczyć zarówno zadań, które są otwarte, jaki i zostały już uprzednio zamknięte. Ciekawostką jest fakt, że możemy ustawić graficzny widok dla issue w ramach kart kanban, które wyświetlają się w bardzo przejrzysty sposób i łatwo je przemieszczać po panelu. To na pewno jedna z ciekawszych funkcji.

Helix TeamHub jest niezwykle łatwym narzędziem, które w zakresie logowania, tworzenia nowych projektów, repozytoriów, code review, a także korzystania z Wiki i przeglądania zgłoszeń na kartach kanbanowych, nie sprawia użytkownikowi najmniejszych problemów. Jego unikalna funkcja dotyczy przede wszystkim obsługi na jednej platformie wielu typów repozytoriów, co zdecydowanie ułatwia administrowanie projektami.

TeamHub posiada także szereg innych funkcjonalności, które nie zostały przedstawione w artykule, a o których możesz dowiedzieć się bezpośrednio ode mnie. Jeśli chcesz wiedzieć więcej o wsparciu jakie daje Helix TeamHub w procesie tworzenia oprogramowania, skontaktuj się proszę ze mną.