W oparciu o wcześniejsze doświadczenia z bazą kodu Big Ball Of Mud, która ewoluowała naturalnie przez wiele lat z rąk wielu młodszych programistów bez nadzoru, chciałbym zwrócić uwagę na to, co się stanie, gdy nie ćwiczysz CI z tymi programistami.
Edycja / Aktualizacja : Zgodnie z komentarzem RubberDuck; w tej odpowiedzi założono, że celem scalania dla integracji jest gałąź rozwoju, a nie gałąź oceny lub wydania.
- Oczywiście musi istnieć znacznie większa kontrola nad kodem w celu wydania i wdrożenia na żywo; jeśli nie ma oddzielnej gałęzi produkcyjnej, warto rozważyć zmianę strategii rozgałęziania / scalania, aby uruchomić główną gałąź programistyczną (która służy do testowania integracji, a nigdy do wydania) obok gałęzi głównej. Zachowuje to wszystkie zalety CI i częste łączenia bez ryzyka złamania kodu produkcyjnego.
1. Młodsi programiści rzadziej komunikują się ze swoimi współpracownikami lub przełożonym
Ciągła integracja to nie tylko kwestia scalenia kodu, to moment, w którym programista jest zmuszony do interakcji z innymi interesariuszami.
Komunikacja jest ważna i bez nadmiernej uogólnienia jest to umiejętność wyuczona, która dociera mniej naturalnie do niedoświadczonych programistów niż do tych, którzy są przyzwyczajeni do pracy w środowisku zespołowym.
Jeśli pozwolisz młodym programistom siedzieć w swojej kabinie i walczyć o kod przez wiele tygodni, bez konieczności częstych raportów / recenzji, wtedy bardziej prawdopodobne jest, że całkowicie unikną komunikacji.
2. Kod, który tworzą, prawdopodobnie będzie wymagał bardziej rygorystycznej weryfikacji
Czy kiedykolwiek recenzowałeś coś, co było tak złe, że żałowałeś, że nie odebrałeś go wcześniej i nie dopuściłeś do napisania? To się często zdarza.
Nie można zapobiec pisaniu złego kodu, ale można ograniczyć straty czasu. Jeśli zobowiązujesz się do częstych recenzji i fuzji, minimalizujesz zakres zmarnowanego czasu.
Najgorszym scenariuszem jest to, że możesz zostawić młodszego programistę w spokoju na kilka tygodni w jego własnym miniaturowym projekcie, a kiedy są oni w końcu gotowi do przeglądu kodu, po prostu nie ma wystarczająco dużo czasu, aby rzucić cały bałagan i zacznij od nowa.
Wiele projektów staje się wielką kulą błota po prostu dlatego, że napisano cały ładunek złego kodu, kiedy nikt nie zwracał uwagi, dopóki nie było za późno.
3. Powinieneś być mniej pewny, że młodszy programista lub inny nowy członek zespołu zrozumiał wymagania
Czasami programista może stworzyć idealne rozwiązanie niewłaściwego problemu; ten jest smutny, ponieważ zwykle wynika z prostych nieporozumień, których tak łatwo byłoby uniknąć, gdyby tylko ktoś zadał właściwe pytanie (pytania) wcześniej.
Ponownie, jest to problem, który bardziej dotyka niedoświadczonych programistów, którzy są bardziej skłonni zaakceptować „złe” wymagania według wartości nominalnej, zamiast odpychać i kwestionować zasadność tego wymagania.
4. Prawdopodobnie będą mniej zaznajomieni ze wspólnymi wzorcami, architekturą istniejącego kodu oraz dobrze znanymi narzędziami i rozwiązaniami
Czasami deweloper spędza cały czas niepotrzebnie wymyślając koło, ponieważ nie wiedzieli, że istnieje nawet lepsze rozwiązanie. Lub spędzają dni próbując wbić kwadratowy kołek w okrągły otwór, nie zdając sobie sprawy z tego, co robią źle.
Ponownie, tego rodzaju rzeczy częściej zdarzają się niedoświadczonym programistom, a najlepszym sposobem rozwiązania tego problemu jest regularne przeglądy.
5. Długie przerwy między zatwierdzeniami / połączeniami kodu utrudniają identyfikację i naprawę defektów
Kiedy błąd pojawia się natychmiast po scaleniu zmian kodu o wiele tygodni w gałęzi master, trudność w określeniu, która zmiana mogła spowodować błąd, staje się trudniejsza.
Oczywiście w grę wchodzi również ogólna strategia rozgałęziania; idealnie wszyscy twoi programiści będą albo pracować we własnych gałęziach, albo w gałęziach funkcji (lub w obu) i nigdy nie będą pracować bezpośrednio z poziomu głównego / głównego.
Widziałem sytuacje, w których całe zespoły jednocześnie pracują bezpośrednio nad mistrzem / pniem, i jest to straszne środowisko dla CI, ale na szczęście rozwiązanie odciągnięcia wszystkich od mistrza / pnia ogólnie zapewnia wystarczającą stabilność do indywidualnej pracy przedmioty / bilety / itp.
Zawsze powinno być „OK” dla każdego dewelopera, aby złamać gałąź master / trunk, przy założeniu, że łączenie powinno odbywać się tak regularnie, że przełamywanie zmian i defektów powinno być rozpoznawane szybciej, a zatem również szybciej usuwane. Najgorsze wady to zazwyczaj te, które pozostają niewykryte przez miesiące, a nawet lata.
W podsumowaniu; główne zalety ciągłej integracji / ciągłego wdrażania to:
- Poprawia się komunikacja między zespołem
- Jakość kodu jest generalnie utrzymywana na wyższym poziomie
- Wymagania są mniej prawdopodobne, że zostaną pominięte lub źle zinterpretowane
- Problemy z architekturą i projektowaniem powinny być wykrywane szybciej,
- Wady są częściej wykrywane i naprawiane na wcześniejszym etapie
Więc jeśli nie ćwiczysz CI ze swoimi młodszymi programistami, to akceptujesz wiele znaczącego niepotrzebnego ryzyka, ponieważ są to członkowie twojego zespołu, którzy potrzebują go bardziej niż reszta.
it is more scary to wait a week to deploy all micro services at once to make sure that everything works together, than to strictly enforce api versioning, write lots of automatic tests (...), and auto deploy to production as soon as your commit passes as tests on stage- to oparte na opiniach;) IMHO o wiele trudniej jest zapewnić sukces przy niezależnym wdrażaniu usług niż przy monolitycznym podejściu: softwareengineering.stackexchange.com/a/342346/187812 . A dzięki prawdziwemu CI (bez gałęzi funkcji / integracji) nie powinieneś czekać przez tydzień.