Masz oddział produkcyjny lub używasz master?

Pracuję w małym zespole z innymi zdalnymi programistami nad Railsaplikacją. Zaczynamy modyfikować nasz gitprzepływ pracy. Pomyśleliśmy o strukturze rozgałęziającej, jak poniżej:

(dev) -> (qa) -> (stag) -> (master)

Ale niektórzy programiści sądzili, że może to być mniej mylące dla nowych programistów, którzy mogą automatycznie naciskać na produkcję na master. Zamiast tego pomyśleli, że wszyscy pracują nad masterem i tworzą oddzielną gałąź produkcji.

(master) -> (qa) -> (stag) -> (prod)

Nauczono mnie, że chcesz, aby wzorzec można było wdrażać i nie używać go jako wersji programistycznej, a z poprzednich miejsc, w których pracowałem, wzorzec jest zawsze przeznaczony do wdrożenia w środowisku produkcyjnym.

Jakie byłyby wady stosowania struktury rozgałęziającej, w której master jest aktywnie wykorzystywany do programowania, a oddzielna gałąź prod jest tym, czego używasz do wdrożeń?

Takie podejście nie ma żadnych zalet ani wad. Powód, dla którego mówię, jest prosty: dla Gita nie ma znaczenia, czy rozwijasz się z mistrza, czy wypuszczasz z niego. Nie musisz nawet zwalniać gałęzi; zamiast tego możesz oznaczyć dowolne zatwierdzenie i zwolnić je.

Prawdziwym problemem tutaj jest jednym z procesów i procedur. Im więcej starszych deweloperów, którzy są zaniepokojeni, że zrobienie tego w jeden sposób wprowadzi zamieszanie, nowi deweloperzy muszą być przygotowani na poświęcenie czasu na wyjaśnienie, czym jest model wydania i dlaczego tak jest.

Tak długo, jak wszyscy rozumieją, że master jest przeznaczony do programowania, a jakaś inna arbitralna gałąź dotyczy wydań, a praca nad utrzymaniem tego jest wykonywana , to nie powinno być żadnych problemów z tym podejściem.

Widzę twój dylemat. Ja też to miałem, dopóki nie zrozumiałem, co zawsze zakładałem o mistrzu.

Nauczono mnie, że chcesz, aby wzorzec można było wdrażać i nie używać go jako wersji programistycznej, a z poprzednich miejsc, w których pracowałem, wzorzec jest zawsze przeznaczony do wdrożenia w środowisku produkcyjnym.

Z dokumentacji / książki Gita - Rozgałęzienie Gita

Oddział „master” w Git nie jest oddziałem specjalnym. Jest dokładnie tak, jak każda inna gałąź. Jedynym powodem, dla którego prawie każde repozytorium ma takie, jest to, że polecenie git init tworzy je domyślnie i większość ludzi nie zadaje sobie trudu, aby je zmienić.

Tak więc, jeśli masz preferowany przepływ pracy i trudno jest z nim pracować, ponieważ różni programiści w zespole mają różne pomysły na ten temat master. Możesz nawet rozważyć zmianę nazwy, masteraby powiedzieć prodi użyć przepływu pracy takiego jak poniżej -

(dev) -> (qa) -> (stag) -> (prod)

Oto jak zmienić nazwę gałęzi głównej .

NIE mówię, że musisz zmienić masternazwę oddziału. Ale jeśli masz preferowany przepływ pracy i pomaga to zmienić masternazwę oddziału, zrób to za pomocą wszystkich środków :-)

W tym przypadku wolę kontrole niż konwencje. Każdy zespół składa się z członków, którzy są lepsi w uruchamianiu nowych funkcji, oraz innych ludzi, którzy są lepsi w stabilizowaniu rzeczy na potrzeby wydania.

Jeśli nie masz tego drugiego, recenzje kodu pomogą (często bardziej zdyscyplinowani ludzie i tak będą chcieli przeglądać kod).

Właśnie dlatego konfigurujemy nasze repozytorium Git (korzystamy z Gitlab), aby tylko niektóre osoby mogły scalać żądania ściągania, a każdy programista otrzymuje własny prywatny widelec głównego repozytorium.

To rozwiązuje dwa problemy:

1. Nowi programiści nie mogą zmienić niewłaściwej gałęzi (ponieważ nie mogą pchnąć swojej pracy bezpośrednio do głównego repozytorium). Mogą naciskać masterna własne repozytorium, ale zostanie to naprawione, gdy pojawi się żądanie ściągnięcia.

2. Konwencje kodu szybko rozprzestrzeniają się w zespole, ponieważ każde zatwierdzenie jest sprawdzane przez co najmniej inną osobę, która przedstawia swoją opinię i wiedzę.

Wszystko zależy od ogólnego procesu tworzenia oprogramowania. Zarządzanie konfiguracją i sposób tworzenia nowej wersji nie mogą zostać zdefiniowane bez wiedzy na temat całego procesu.

Istnieje frakcja „zwinna”, która wybrałaby „zawsze działający obszar pierwszego zatwierdzenia”. Będą stale uruchamiać zautomatyzowane urządzenia do budowania i testowania w tym obszarze i starają się mieć działający system „przez cały czas”.

Uważaliby (master) -> (release) z organizacją może 1,2 pośrednich kroków za korzystną.

Następnie istnieje bardziej „klasyczna” frakcja, której proces opiera się na planowaniu i planowanych krokach integracji w kierunku kamieni milowych, w których wydanie „jednostki pracy” jest zaplanowanym działaniem z wymaganiami, takimi jak „wydanie tylko, gdy jest (testowane) i powinien pasować do następnego planowanego kamienia milowego ". Tam planowanie obejmuje wersjonowanie „jednostek pracy” i zazwyczaj dokładają one wszelkich starań, aby określić, jak ma wyglądać następna planowana wersja produktu pod względem funkcji i poprawek. W trosce o planowanie chcą wiedzieć, że to, co programista wydaje, jest „właściwe” i świadomy akt popełnienia jednostki pracy.

To klasyczne podejście niekoniecznie oznacza, że ​​istnieją dłuższe czasy, w których nie jest dostępna pełna wersja produktu.

Tak więc „klasyczny” obieg pracy wyglądałby następująco: (dev) -> (jednostka) -> (integracja) -> (test / qa) -> (produkcja).

Rolą integratora jest „akceptowanie / kupowanie” wydanych jednostek lub odrzucanie ich, jeśli nie odpowiadają one potrzebom kolejnego nadchodzącego wydania.

Na marginesie można również łączyć te dwa podstawowe podejścia w odpowiedni sposób.

Z mojego doświadczenia (które dotyczyło głównie zastosowania „klasycznego” podejścia), „klasyczne” podejście działało całkiem dobrze w projektach od około 4–50 osób w zespole.