Dzisiejszy post z braku konkretnego pomysłu oraz zdecydowanie czasu. Wszyscy piszą o tym jakie to CI (continus integration) jest dobre. I zgadzam się z tym pod pewnymi warunkami. Cały proces musi być dobrze przemyślany i skonfigurowany. W studium przypadku opowiem jak proces może być źle przemyślany oraz w kilku punktach zwrócę uwagę na to co można zrobić lepiej.

Elementy składowe

Co składa się na proces CI ? W projektach, w których pracowałem było to zazwyczaj:

• Automatyczny build
• Testy jednostkowe
• Generacja dokumentacji (automat generujący dokumentację z kodu)
• Stworzenie pliku instalatora

Czy to wszystko ? A może czegoś brakuje ? To zależy  czego oczekujemy od CI w tym konkretnym przypadku.

Studium przypadku

Dzisiaj o jednym z projektów, w którym miałem możliwość pracować.

Proces CI był tam mało powiedziane kiepski. Używaliśmy TFS-a  i gatedCheck-in, czyli zanim zmiany były widoczne dla wszystkich cały proces CI musiał zostać zakończony sukcesem. Cały proces czyli build-testy jednostkowe-Statyczna analiza kodu. Nie brzmi strasznie prawda ? Ale było czas od próby check-ina do faktycznego check-ina to około 20-25 minut i to bez kolejki bo niestety przy takim sposobie pracy zmiany musiały być procesowane jednowątkowo. Wiecie jak wspaniałą była informacja, że jesteśmy czwartą czy piątą osobą w kolejce oczekujących, albo że nasza zmiana nie wchodzi do repozytorium przez merge-conflikty. Ten proces wymagał naprawy niestety nie było nam dane tego zrobić. Ale dane nam było wystrzegać się tego w kolejnych projektach. Kilka wytycznych i pomysłów, jeśli przyjdzie wam tworzyć proces CI.

Czas wprowadzenia zmian w repozytorium

Im szybciej zmiany będą dostępne dla wszystkich, tym mniej konfliktów przy procesie. Z tego powodu nasz system w kolejnym projekcie wprowadzał zmiany do brancha developerskiego, co uruchamiało proces CI, nigdy więcej w drugą stronę.

Wielowątkowo

Kiedy zmiany są wprowadzane od razu do repozytorium kodu możemy pomyśleć o drugim elemencie, wielowątkowości. Jeśli możemy sobie pozwolić na kilka maszyn budujących, żeby zmiany były testowane na bieżąco, to super mamy spore szanse, aby proces nie był zbyt uciążliwy. Jeśli musimy działać na jednej maszynie trzeba pomyśleć czy w procesie nie można by czegoś zoptymalizować.

Niezbędne minimum

Mamy zmiany w kodzie szybko, niestety maszyna budująca tylko jedna. Jak to przyśpieszyć ? Pomyśl czy wszystkie elementy są konieczne przy każdym uruchomieniu procesu. Może dałoby się przeżyć bez generowania dokumentacji, albo bez wszystkich testów (zanim zostanę posądzony o świętokradztwo nie namawiam do nie uruchamiana testów,  a jedynie do sprawdzenia czy nie dałoby się wybrać subsetu takich krytycznych). Wszystkie tak celowo pominięte kroki można uruchamiać w dodatkowym uruchomieniu procesu w godzinach nocnych.

Nieuchronne faile

Teraz o czymś co stanie się na pewno i na co powinniśmy się przygotować w tak skrojonym procesie. Warto przedyskutować jak naprawiamy kod po tym jak proces CI wykryje błędy. U mnie, kiedy ktoś popsuł builda/testy cokolwiek był odpowiedzialny za naprawę. Jeśli to był test to można było wprowadzać zmiany dalej, jeśli źródła się nie budowały należało się wstrzymać lub w porozumieniu z winowajcą naprawić. Jeśli byliśmy zmuszeni odłożyć coś na później, pierwszą czynnością rano było sprawdzenie czy w nocy wszystko przeszło bez problemów i ewentualnie naprawa tego co się popsuło.