Opieka nad systemem ciągłej integracji

Jedną z moich ról w zespole jest osoba budująca . Jestem odpowiedzialny za utrzymanie / aktualizację naszych skryptów kompilacji i upewnienie się, że budujemy „płynnie” na serwerze ciągłej integracji. Zwykle nie mam nic przeciwko tej pracy, chociaż często mam wrażenie, że ciągle opiekuję się serwerem CI.

Ta praca może być irytująca, ponieważ jeśli kompilacja się zepsuje, muszę opuścić historię, nad którą pracuję i zbadać jej niepowodzenie. Awarie kompilacji zdarzają się codziennie w naszym zespole. Czasami programiści po prostu nie budują lokalnie przed zatwierdzeniem, więc testy na serwerze CI kończą się niepowodzeniem. W tej sytuacji lubię szybko docierać do osoby, która miała „złe zatwierdzenie”, aby kompilacja nie została zepsuta zbyt długo. Czasami (znacznie rzadziej) na serwerze CI występuje dziwny warunek, który należy debugować.

Wiem, że wiele dojrzałych zespołów stosuje ciągłą integrację, ale nie ma zbyt wielu materiałów na temat dobrych praktyk.

Czy moje problemy wskazują, że nasza ciągła integracja nie jest zbyt dojrzała, czy jest to po prostu część pracy?

Jakie są dobre praktyki, których należy przestrzegać? Jakie są cechy dojrzałej ciągłej integracji ?

Aktualizacja

Zamiast odpowiadać na niektóre komentarze, zamierzam dokonać aktualizacji. Mamy jedno, proste polecenie, które robi dokładnie to, co zrobi serwer kompilacji podczas budowania aplikacji. Skompiluje, uruchomi wszystkie jednostki / integrację i kilka szybkich testów opartych na interfejsie użytkownika.

Czytając odpowiedzi wszystkich, wydaje się, że możemy mieć dwa główne problemy.

1. Serwer CI nie narzeka wystarczająco głośno, gdy kompilacja się nie powiedzie.
2. Programiści nie czują się odpowiedzialni za to, aby ich zatwierdzenie przebiegło pomyślnie.

W moim zespole trudniejsze jest to, że mamy duży zespół (ponad 10 programistów) ORAZ mamy kilku członków zespołu off-shore, którzy zobowiązują się, gdy nawet nie jesteśmy w pracy. Ponieważ zespół jest duży i ustaliliśmy, że preferowane są częste, małe zobowiązania, czasami mamy naprawdę dużo aktywności w ciągu jednego dnia.

Przede wszystkim: każda osoba jest odpowiedzialna za proces kompilacji . Wygląda na to, że członkowie Twojego zespołu nie są dojrzali ... Nikt nie unika pisania kodu i fobowania go na serwerze CI, mając nadzieję, że zadziała. Przed zatwierdzeniem kodu należy go przetestować na komputerze lokalnym. Powinieneś być pewien, że kod, który sprawdzasz, nie spowoduje uszkodzenia kompilacji. Oczywiście zdarzają się przypadki, gdy kompilacja przerywa się niezamierzenie (np. Jeśli plik konfiguracyjny został zmieniony lub niechciane zatwierdzenie zostało wykonane przypadkowo).

Większość serwerów CI (użyłem tylko Hudsona) wyśle ​​automatyczną wiadomość e-mail z wyszczególnieniem dokonanych zmian, które spowodowały przerwanie kompilacji. Jedyną częścią twojej roli jest stać za nimi i wyglądać twardo, dopóki podejrzany nie naprawi tego, co złamali.

Twój zespół źle zrozumiał:

Odpowiedzialność za serwer kompilacji to nie to samo, co odpowiedzialność za kompilację .

Obowiązkiem osoby sprawdzającej kod jest uczynienie go „działającym” (dla pewnej wartości pracy). Jedynym powodem posiadania serwera kompilacji jest uchwycenie niedopatrzeń w tym procesie. Każdy serwer kompilacji wart swojej soli może powiadomić osobę (osoby), która zarejestrowała kod od czasu ostatniej kompilacji (a także każdą inną osobę zainteresowaną) o następujących informacjach:

• Kompilacja zepsuta!
• Co poszło nie tak podczas budowania!
• Co się zmieniło od ostatniej wersji!

Bardzo często zdarza się to przez e-mail. Ważne jest, aby stało się to dość szybko po każdej odprawie.

Osoba może następnie zobaczyć, co poszło nie tak, i naprawić, a następnie serwer kompilacji powiadamia wszystkich zainteresowanych, że kompilacja powróciła do normy. Powinno to nastąpić samoistnie, bez udziału innych osób, ale winowajcy odprawy.

Aby odpowiedzieć na twoje pytanie: Dojrzałe środowisko CI NIE wymaga zaangażowania woźnego w jego normalne działanie.

Ponadto, jeśli „dziwne warunki” zdarzają się bardzo często, dowiedz się, co je powoduje, i spraw, aby system był solidniejszy.

Zmień proces. Jeśli zatwierdzenie przerwie kompilację, automatycznie wycofaj zatwierdzenie i powiadom dewelopera, który go złamał. Niemądrze jest pozwolić, aby błąd jednego członka zespołu spowolnił resztę zespołu. Lub zamiast wykonywania kompilacji integracyjnych automatycznie, poproś programistów o sprawdzenie maszyny integracyjnej, a jeśli kompilacja się powiedzie, mogą zatwierdzić. Ciągła integracja nie oznacza „sprawdź, co ci się podoba, a ktoś to naprawi”.

Strategia „złotej gałęzi” nie działa, dopóki nie ma strażnika złotej gałęzi.

DVCS taki jak Git może pomóc; zamiast zatwierdzenia programista może po prostu przesłać zestaw zmian do integracji z serwerem CI, a następnie serwer może podjąć próbę zintegrowania zestawu zmian. Jeśli integracja się powiedzie, zestaw zmian zostanie scalony, a jeśli nie, zostanie odrzucony.

Jednym z problemów, które często widzę, jest to, że programiści nie mogą wykonać kompilacji lokalnej, która ma dokładnie takie same kroki jak kompilacja CI. Oznacza to, że serwer CI jest skonfigurowany tak, aby zawierał dodatkowe kroki, takie jak testy jednostek / integracji, zasięg itp., Których nie można wykonać lokalnie. Nieuchronnie programiści ugryzą jeden z kroków, których nie mogą wykonać lokalnie, i zaczną pytać, dlaczego w ogóle starają się zbudować wersję lokalną przed odprawą.

Całą moją kompilację trzymam samowystarczalną, a serwer CI po prostu rozpoczyna kompilację wersji bez żadnych dodatkowych konfiguracji / kroków. Programiści mogą uruchomić kompilacji uwolnienia lokalnie przed check-in, która obejmuje wszystkie czynności, które będą wykonywane przez kompilacji CI i znacznie większą pewność, że nic nie złamie, kiedy zrobić check-in.

Dodatkowe zalety tego podejścia obejmują:

• przełączanie się między serwerami CI jest łatwe, ponieważ nie zainwestowałeś dużo czasu w konfigurowanie zbędnych kroków
• całe narzędzie do budowania jest pod kontrolą źródła, co oznacza, że ​​wszyscy programiści używają dokładnie tego samego zestawu narzędzi do budowania systemu
• oprócz powyższego punktu, można łatwo modyfikować oprzyrządowanie kompilacji w kontrolowany sposób

PS. cała koncepcja budowania opiekunki do dziecka jest niedorzeczna, ale inni to opisali.

Po pierwsze, programiści nie powinni regularnie przerywać kompilacji - powinni budować i uruchamiać testy lokalnie przed zatwierdzeniem ich w gałęzi CI. Wstrzymanie kompilacji powinno być oznaką wstydu i ważne jest, aby to egzekwować. Zrobiłem to za pomocą statystyk publikowania i widziałem, jak inne zespoły mają „torbę budowania”, w której wkładasz dolara za każdym razem, gdy przerywasz kompilację. Pod koniec projektu pieniądze przeznaczane są na piwo.

Jeśli wstyd / duma osobista nie działa, być może będziesz musiał przejść do cięższych rzeczy (np. Groźba zakończenia pracy). Złamanie kompilacji przed wyjazdem na dzień powinno być poważnym przestępstwem. I każdy programista powinien mieć powiadomienie o stanie kompilacji na swoim komputerze. Najlepsze w tym wszystkim jest to, że zachęca do mniejszych zatwierdzeń, które i tak są preferowane.

To powiedziawszy, kompilacja czasami się psuje (na przykład przyczyny konfiguracji CI). A czasami ludzie spieprzą i wychodzą na dzień ze zepsutą kompilacją. Dlatego powinieneś dążyć do procesu, który pozwala na szybkie i łatwe wycofanie znanych dobrych wersji. Jeśli zawsze możesz cofnąć się do ostatniej dobrej wersji (i mieć wycofaną wersję wdrożoną we wszystkich niezbędnych miejscach), to w najgorszym przypadku zepsutej wersji, w której sprawca zostawił na wieczór, możesz rzucić wróć do ostatniej dobrej wersji i krzycz na niego rano.

Nie mogę wystarczająco polecić książki Continuous Delivery . Jeśli szukasz przewodnika na temat dojrzewania procesu CI, spróbuj.

Słyszałem o rzeczy, którą Microsoft (być może?) Robi, a mianowicie o tym, że rolą kompilacji opiekunki jest poruszanie się po zespole. Robią to w ten sposób, że gdy ktoś psuje kompilację (co prawdopodobnie powinno obejmować sprawdzanie czegoś, co nie przejdzie testów), przejmuje rolę. To sprawia, że ​​ludzie są odpowiedzialni za konsekwencje swoich działań w bardzo bezpośredni sposób. Biorąc pod uwagę, że jest to dość denerwujące zadanie, zachęca ich, aby nie przerywali kompilacji ponownie.

Osoba odpowiedzialna obecnie za kompilację może mieć specjalny kapelusz. Może być ceremonia wręczenia go.

Zauważ, że jak mówi Thorbjørn, odpowiedzialność za kompilację to nie to samo, co odpowiedzialność za serwer kompilacji. Odpowiedzialność za serwer może spoczywać na stałe na jednym lub kilku członkach zespołu skłonnych do korzystania z infrastruktury, podczas gdy odpowiedzialność za kompilację się zmienia.

Teraz, pomijając szczegóły procesu, dołączę do chóru ludzi wyrażających konsternację podczas sprawdzania deweloperów bez uruchamiania kompilacji i testowania. Gorszący!

Jeśli masz członków zespołu, którzy są bardziej skłonni do złamania kompilacji (i na podstawie mojego własnego doświadczenia, głównie myślę o członkach z innego kraju) i jeśli używasz ładnej nowoczesnej kontroli źródła, takiej jak Mercurial lub Git, możesz poprosić ich, aby zameldowali się w innym oddziale niż reszta zespołu, uruchomili na tym osobny proces CI i automatycznie scalili zmiany z tej gałęzi do magistrali po udanej kompilacji (pamiętaj, że będziesz musiał uruchom drugą kompilację i przetestuj po scaleniu przed sprawdzeniem scalenia w!). Ponieważ automatyczne łączenie nie zawsze kończy się powodzeniem, w końcu oddział wymagałby ręcznej uwagi, co może być prawdziwym bólem. Może to być mniej bolesne niż zerwanie kodu przez resztę zespołu.

Jak powiedział Jonathan Khoo, wszyscy powinniście być odpowiedzialni za serwer kompilacji i skrypt kompilacji. Istnieją trzy powody:

1. W tej chwili masz przypadek „Bus 1”, co oznacza, że ​​jeśli zostałeś przejechany przez magistralę, cała wiedza na temat serwera kompilacji i skryptów kompilacji zostanie utracona.
2. Skrypty, które zostały napisane przez ciebie (słusznie lub niepoprawnie), miały tylko twój wkład. Tak jak każdy kod, im więcej zaangażowanych osób, tym szersza baza wiedzy, którą można zastosować.
3. Wreszcie, gdy coś pójdzie nie tak, odczuwasz ból. Ból jest dobrą rzeczą, ale nie kiedy jest izolowany. W tej chwili masz do czynienia z bólem, ale jeśli wszyscy inni cierpią z tego powodu, przekonasz się, że w końcu będą bardziej rygorystyczni w testowaniu kodu przed popełnieniem.

Jestem bardzo zaangażowany w CI i wpadam w pułapkę bycia tym, który utrzymuje skrypty, ale oto kilka rzeczy, które możesz zrobić, aby to złagodzić.

1. Skrypty kompilacji powinny być uruchamiane nie tylko na serwerach CI, ale także na lokalnych komputerach programistycznych. Powinny wytwarzać te same dane wyjściowe, uruchamiać te same testy i kończyć się niepowodzeniem z tych samych powodów. Pozwala to programistom na uruchomienie skryptu przed zatwierdzeniem kodu.
2. Jeśli ktoś złamie kompilację, upublicznij ją za pomocą wyskakujących okienek zadań, wiadomości e-mail, migających świateł, dźwięków itp. Służy to nie tylko zawstydzeniu członków zespołu, ale zapewnia wszystkim innym członkom zespołu możliwość wstania i wspierać.
3. Przez chwilę unikaj poprawiania kompilacji. Niech ktoś to zrobi. Jeśli nikt inny nie podskoczy, poczekaj, aż wydarzy się coś złego, i wykorzystaj go jako punkt do nauki dla całego zespołu, aby zrozumieć, dlaczego serwer CI jest ważny.
4. Staraj się, aby serwer kompilacji i maszyny programistyczne były jak najbardziej pozbawione zainstalowanych komponentów firm trzecich, szczególnie utrzymuj GAC w czystości. Polegaj na komponentach innych firm znajdujących się w folderze biblioteki projektów. Pomaga to szybciej zidentyfikować brakujące komponenty.

Widoczność ci pomoże. Wszyscy członkowie zespołu muszą wiedzieć, że istnieje aktywny problem, który powinni naprawić. Powiadomienia e-mailowe są przydatne, ale jeśli programista jest zajęty i nie zareaguje natychmiast, prawdopodobnie o nim zapomni, a wiadomość e-mail skończy się na ogromnym stosie powiadomień.

Możesz spróbować użyć narzędzi takich jak Catlight lub BuildNotify . Pokazują aktualny status ważnych kompilacji w obszarze zasobnika. Za każdym razem, gdy programista patrzy na zegar, widzi, że istnieje zepsuta kompilacja, którą należy naprawić.

Catlight pokaże także, kto pierwszy przełamał kompilację, wywierając na nią presję społeczną, ponieważ cały zespół zobaczy ją przy każdej kolejnej awarii kompilacji.

Jedną strategią jest użycie wielu małych oddziałów do wielu małych projektów. Potem, gdy ktoś psuje kompilację, po prostu psuje kompilację dla siebie. Otrzymują więc zirytowany e-mail z serwera kompilacji i to od nich zależy.

Kolejnym jest poprawa poziomu odpowiedzialności ludzi. Na przykład, jeśli używasz czegoś takiego jak Rietveld, ludzie nie mogą popełnić błędu bez przejrzenia recenzji. (W praktyce proces ten jest o wiele lżejszy niż myślisz. Ale zmusza ludzi do „potokowania” i pracy nad wieloma rzeczami jednocześnie.) Za zachowanie kompilacji odpowiedzialny jest zarówno autor, jak i recenzenci. Jeśli ktoś albo regularnie psuje kompilację, albo zatwierdza rzeczy, które ją psują, nie pozwól, by ostatecznie zatwierdził kompilację. Połącz z procesem, w którym każdy może łatwo wycofać każdą zmianę, a kompilacja nie będzie tak często się łamać i nie pozostanie zerwana po wprowadzeniu zmiany.

Zamierzam tu zerwać z refrenem i powiedzieć, że w rzeczywistości od czasu do czasu przerwanie kompilacji nie jest takie złe, ponieważ pokazuje, że faktycznie wykonuje się pracę. Tak, programiści powinni budować i testować, zanim popełnią, ale główny ciężar testowania powinny ponosić narzędzia automatyzacji programowania, w tym serwer ciągłej integracji. Narzędzia są do użycia, a jeśli kompilacja nie zostanie przerwana od czasu do czasu, nie jest jasne, czy naciskasz tak mocno, jak tylko możesz. Uważam jednak, że kompilacja nigdy nie powinna nigdy ulec uszkodzeniu przez dłuższy czas, a nawet sprzyjałbym automatycznemu wycofywaniu lub wieloetapowemu procesowi zatwierdzania, jeśli pomaga to w realizacji podwójnych celów szybkiej informacji zwrotnej ze scentralizowanych, zautomatyzowanych urządzeń testowych, plus „zielony” pień.

Łączy rzeczy, o których należy pamiętać:

1. Twój zespół potrzebuje zestawu standardów do przestrzegania
2. Musisz wdrożyć zarządzanie z ideą czystego kodu i dążyć do poprawy praktyk w zakresie kodu.
3. Test testowy test! Zawsze sprawdzaj przed odprawą.
4. Chociaż zgadzam się, że przerwanie kompilacji jest w porządku, jest to rzadkie i mam na myśli niezwykle rzadką okazję, która byłaby do przyjęcia. Jeśli tak jest codziennie, szukałbym drzwi lub rozmawiał z szefem o standardach.

Ogólnie rzecz biorąc, musicie ustalić, napisać standardy oparte na najlepszych praktykach, a nie na swoich praktykach indywidualnie (oczywiście te się nie sprawdzają). Gdy wszyscy uzgodnią standardy, rozpocznij proces przeglądu kodu i egzekwowania standardów. Wygląda na to, że zarząd pojechał na wakacje i nigdy nie wrócił. Są to rzeczy, które szczerze mówiąc są dość podstawowe dla każdego sklepu. podstawy dobrego kodu zaczynają się od dobrych standardów dyktowania kodu zespołu i sposobu jego pisania. Tylko moje myśli. Niedawno znalazłem się w podobnej sytuacji w nowej pracy i rozmawiałem z szefem. Wyjaśniono mu, że musimy ukończyć XYZ, ponieważ wpływa to na ABC. Dwa tygodnie później napisałem listę standardów kodu do naśladowania i przedstawiłem ją. Następnie podążyli za mną moi współpracownicy i około 2 miesiące później wprowadziliśmy standardy, które rozwiązały mnóstwo problemów.