Dlaczego Git to odpowiednie rozwiązanie dla Twojej organizacji
Przejście ze scentralizowanego systemu kontroli wersji na Git zmienia sposób, w jaki zespół programistyczny tworzy oprogramowanie. Jeśli Twoja firma korzysta z oprogramowania do zastosowań o znaczeniu krytycznym, zmiana przepływu prac programistycznych ma wpływ na całą Twoją organizację.
Git dla programistów
Przepływ pracy gałęzi funkcji
Jedną z największych zalet Git jest możliwość tworzenia gałęzi. W przeciwieństwie do scentralizowanych systemów kontroli wersji gałęzie Git są łatwe do scalania. Umożliwia to stosowanie przepływu pracy gałęzi funkcji popularnego wśród wielu użytkowników Git.
Gałęzie funkcji zapewniają izolowane środowisko dla każdej zmiany w bazie kodu. Gdy programista chce rozpocząć pracę nad częścią kodu — bez względu na to, czy jest duża, czy mała — tworzy nową gałąź. Dzięki temu gałąź główna zawsze zawiera kod o jakości nadającej się do wdrożenia w środowisku produkcyjnym.
Korzystanie z gałęzi funkcji jest nie tylko bardziej niezawodne niż bezpośrednia edycja kodu produkcyjnego, ale także zapewnia korzyści organizacyjne. Pozwalają one reprezentować prace programistyczne z taką samą szczegółowością jak backlog Agile. Przykładowo można zaimplementować zasady, zgodnie z którymi każde zgłoszenie Jira jest rozwiązywane we własnej gałęzi funkcji.
materiały pokrewne
Git — ściągawka
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
Programowanie rozproszone
W SVN każdy programista otrzymuje kopię roboczą, która odnosi się do pojedynczego centralnego repozytorium. Inaczej jest w Git, który jest rozproszonym systemem kontroli wersji. Zamiast kopii roboczej każdy programista otrzymuje własne lokalne repozytorium wraz z pełną historią commitów.
Dzięki pełnej historii lokalnej Git jest szybki, ponieważ nie potrzebujesz połączenia sieciowego do tworzenia commitów, sprawdzania poprzednich wersji pliku czy analizowania różnic między commitami.
Programowanie rozproszone ułatwia również skalowanie zespołu inżynierskiego. Jeśli ktoś uszkodzi gałąź produkcyjną w SVN, inni programiści nie mogą wprowadzić swoich zmian, dopóki nie zostanie ona naprawiona. W Git tego rodzaju wąskie gardło nie istnieje. Każdy może kontynuować swoją pracę we własnym lokalnym repozytorium.
Podobnie jak w przypadku gałęzi funkcji programowanie rozproszone tworzy bardziej niezawodne środowisko. Nawet jeśli programista uszkodzi własne repozytorium, może po prostu sklonować repozytorium kogoś innego i zacząć od nowa.
Polecenia pull request
Wiele narzędzi do zarządzania kodem źródłowym, takich jak Bitbucket, rozszerza podstawowe funkcje Git o pull requesty. Pull request jest sposobem poproszenia innego programisty o scalenie jednej z Twoich gałęzi z jego repozytorium. Nie tylko ułatwia to liderom projektów śledzenie zmian, ale także pozwala programistom zainicjować dyskusje na temat ich pracy przed jej zintegrowaniem z resztą bazy kodu.
Dzięki temu, że są w zasadzie wątkiem komentarzy dołączonym do gałęzi funkcji, pull requesty są niezwykle wszechstronne. Gdy programista utknie na trudnym problemie, może otworzyć pull request, aby poprosić resztę zespołu o pomoc. Z kolei młodsi programiści traktując pull requesty jako formalny przegląd kodu, mogą mieć pewność, że nie zniszczą całego projektu.
Społeczność
W wielu kręgach Git stał się pożądanym systemem kontroli wersji w przypadku nowych projektów. Jeśli Twój zespół korzysta z Git, jest wysoce prawdopodobne, że nie będzie trzeba szkolić nowych pracowników w zakresie przepływu pracy, ponieważ będą już zaznajomieni z rozproszonym programowaniem.
Ponadto Git jest bardzo popularny w przypadku projektów open source. Oznacza to, że możesz łatwo wykorzystać biblioteki zewnętrzne i zachęcić innych do utworzenia podziału ich kodu open source.
Szybszy cykl wydawania
Najważniejszym skutkiem wprowadzenia gałęzi funkcji, rozproszonego programowania i pull requestów oraz utworzenia stabilnej społeczności jest szybszy cykl wydawania. Te możliwości pozwalają na wdrożenie przepływu pracy Agile, w ramach którego programiści są zachęcani do częstszego dzielenia się mniejszymi zmianami. To z kolei sprawia, że zmiany można wypychać do pipeline'u wdrożenia szybciej niż w przypadku wydań monolitycznych typowych dla scentralizowanych systemów kontroli wersji.
Jak można się spodziewać, Git bardzo dobrze sprawdza się w środowiskach ciągłej integracji i ciągłego dostarczania. Hooki Git umożliwiają uruchamianie skryptów po wystąpieniu określonych zdarzeń w obrębie repozytorium, co pozwala automatyzować wdrażanie do woli. Można nawet kompilować lub wdrażać kod z określonych gałęzi na różnych serwerach.
Przykładowo można skonfigurować Git tak, aby najnowszy commit z gałęzi programistycznej był wdrażany na serwerze testowym, gdy ktoś scali z nim pull request. Połączenie tego rodzaju automatyzacji kompilacji ze wzajemną weryfikacją oznacza, że możesz mieć najwyższe możliwe zaufanie do kodu, gdy przechodzi on od środowiska programistycznego, przez przejściowe, do produkcyjnego.
Git dla zespołów marketingowych
Aby zrozumieć, jak przejście na Git wpłynie na działania marketingowe Twojej firmy, wyobraź sobie, że Twój zespół programistyczny ma ukończyć w ciągu najbliższych kilku tygodni trzy różne zmiany:
- Cały zespół finalizuje przełomową funkcję, nad którą pracował przez ostatnie pół roku.
- Mary wdraża mniejszą, niepowiązaną funkcję, która wpływa tylko na obecnych klientów.
- Rick wprowadza kilka bardzo pożądanych aktualizacji w interfejsie użytkownika.
Jeśli korzystasz z tradycyjnego programistycznego przepływu pracy, który opiera się na scentralizowanym systemie VCS, przypuszczalnie wszystkie te zmiany zostaną wprowadzone w jednym wydaniu. Zespół marketingowy może przygotować tylko jedno ogłoszenie, które będzie koncentrować się na przełomowej funkcji, a potencjał marketingowy pozostałych dwóch aktualizacji zostanie zmarnowany.
Krótszy cykl programistyczny, możliwy dzięki Git, znacznie ułatwia podzielenie tych funkcji na osobne wydania. To z kolei pozwala zespołowi marketingowemu publikować więcej komunikatów, z większą częstotliwością. W powyższym scenariuszu zespół marketingowy może utworzyć trzy kampanie, które dotyczą każdej z funkcji, a tym samym są ukierunkowane na bardzo konkretne segmenty rynku.
Przykładowo może przygotować dużą kampanię PR dotyczącą przełomowej funkcji, wpis na blogu firmy oraz notkę do biuletynu dotyczącą funkcji opracowanej przez Mary, a także kilka gościnnych postów na temat teorii UX leżącej u podstaw aktualizacji Ricka do opublikowania na zewnętrznych blogach poświęconych projektowaniu. Wszystkie te czynności można zsynchronizować z odpowiednim wydaniem.
Git do zarządzania produktem
Korzyści płynące z Git dla menedżerów produktu są takie same jak w przypadku działów marketingu. Częstsze wydania oznaczają częstsze informacje zwrotne od klientów i szybsze aktualizacje w reakcji na nie. Zamiast czekać na następne wydanie 8 tygodni można wypchnąć rozwiązanie do klientów tak szybko, jak programiści są w stanie napisać kod.
Przepływ pracy gałęzi funkcji zapewnia również elastyczność potrzebną w przypadku zmiany priorytetów. Przykładowo, jeśli jesteś w połowie cyklu wydawania i chcesz przełożyć jedną funkcję na później, aby zastąpić ją pilniejszą, możesz to zrobić bez żadnego problemu. Początkowo planowana funkcja może zaczekać we własnej gałęzi, aż zespół inżynierski będzie miał czas do niej wrócić.
Ta sama funkcjonalność ułatwia zarządzanie innowacjami, testami beta i szybkimi prototypami jako niezależnymi bazami kodu.
Git dla projektantów
Gałęzie funkcji doskonale nadają się do szybkiego prototypowania. Gdy projektanci UX/UI chcą zaimplementować zupełnie nowy przepływ użytkowników albo tylko zastąpić niektóre ikony, wyewidencjonowanie nowej gałęzi pozwala im uzyskać środowisko piaskownicy, w którym mogą eksperymentować. Dzięki temu mogą zobaczyć, jak będą wyglądać ich zmiany w rzeczywistej działającej kopii produktu bez ryzyka utraty istniejącej funkcjonalności.
Zawarcie zmian w interfejsie użytkownika w taki sposób ułatwia zaprezentowanie aktualizacji innym interesariuszom. Przykładowo, jeśli dyrektor działu inżynierskiego zechce zobaczyć, nad czym pracuje zespół projektowy, wystarczy mu przekazać, aby wyewidencjonował odpowiednią gałąź.
Pull requesty rozszerzają tę możliwość, zapewniając zainteresowanym stronom formalne miejsce do dyskusji nad nowym interfejsem. Projektanci mogą wprowadzić niezbędne zmiany, a związane z tym commity pojawią się w pull requeście. W ten sposób wszyscy są zachęcani do udziału w procesie iteracji.
Być może największą zaletą prototypowania z użyciem gałęzi jest fakt, że zmiany jest równie łatwo scalić z kodem produkcyjnym, jak je odrzucić. Jednocześnie nie ma presji, żeby zrobić jedno albo drugie. Dzięki temu projektanci i programiści UI są skłonni do eksperymentowania, a jednocześnie mają pewność, że tylko najlepsze pomysły trafią do klienta.
Git dla działów obsługi klienta
Działy obsługi klienta i sukcesu klienta często mają inne podejście do aktualizacji niż menedżerowie produktu. Gdy klient do nich dzwoni, to zwykle dlatego, że napotykał jakiś problem. Jeśli ten problem jest spowodowany przez oprogramowanie Twojej firmy, konieczne jest jak najszybsze wydanie poprawki błędu.
Usprawniony cykl programowania w Git pozwala uniknąć odkładania poprawek błędów do następnego monolitycznego wydania. Programista może usunąć problem i wypchnąć poprawkę bezpośrednio do środowiska produkcyjnego. Szybsze publikowanie poprawek oznacza bardziej zadowolonych klientów i mniej powtarzających się zgłoszeń do pomocy technicznej. Zamiast cały czas mówić „Przepraszam, zajmiemy się tym”, zespół obsługi klienta może zacząć odpowiadać „Już to naprawiliśmy!”.
Git dla działów zasobów ludzkich
Przepływ pracy tworzenia oprogramowania określa do pewnego stopnia, kogo zatrudniasz. Zawsze dobrze jej zatrudniać inżynierów, którzy znają stosowane w Twojej firmie technologie i przepływy pracy, ale korzystanie z Git zapewnia także inne korzyści.
Pracownicy interesują się firmami, które dają im możliwość rozwoju zawodowego, a szansa na zdobycie wiedzy o tym, jak wykorzystać Git zarówno w dużych, jak i małych organizacjach, będzie zachętą dla każdego programisty. Wybór Git jako systemu kontroli wersji spowoduje, że Twoja organizacja będzie przyciągać programistów myślących przyszłościowo.
Git dla każdego, kto zarządza budżetem
Głównym założeniem Git jest poprawa wydajności. Dzięki niemu programiści nie muszą tracić czasu na przekazywanie commitów przez sieć czy integrowanie zmian ze scentralizowanym systemem kontroli wersji. Git pozwala też lepiej wykorzystać potencjał młodszych programistów, gdyż zapewnia im bezpieczne środowisko do pracy. Wszystko to wpływa pozytywnie na wyniki finansowe Twojego działu inżynierskiego.
Te korzyści nie ograniczają się jednak do zespołu programistycznego. Dzięki Git dział marketingowy nie traci energii na tworzenie materiałów o funkcjach, które nie są popularne. Pozwala też projektantom testować nowe interfejsy w rzeczywistym produkcie przy niewielkich nakładach roboczych. Git umożliwia też natychmiastowe reagowanie na skargi klientów.
Zwinność polega głównie na tym, aby jak najszybciej określać, co działa, zwiększać wysiłki, które przynoszą pozytywne efekty, i eliminować te nietrafione. Git usprawnia wszystkie działania biznesowe, umożliwiając każdemu działowi wydajniejszą pracę.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
