Analizowanie ciągłej integracji
Ciągła integracja to jedna z ośmiu funkcji taksonomii DevOps.
Dowiedz się, dlaczego ciągła integracja jest niezbędna
23 września 1999 roku Mars Climate Orbiter schował swoje tablice słoneczne, aby chronić je przed tymczasowym zejściem do górnej atmosfery marsjańskiej.
Po pomyślnym wejściu na orbitę satelita miał przekazywać zdjęcia Marsa na Ziemię przez kilka lat. Ale niestety, statek spalił się w atmosferze marsjańskiej.
Usterka w oprogramowaniu kontroli naziemnej, która została dostarczona przez inną firmę, obliczyła wartość w jednostce imperialnej w sekundach funta. Oprogramowanie utworzone przez NASA spodziewało się, że wartość będzie znajdować się w jednostce metryki, newton-seconds. Ponieważ te wartości nie zostały poprawnie przekonwertowane, małe rozbieżności w pozycji statku kosmicznego zostały złożone w ciągu milionów mil.
Kontrola jakości nie zauważyła użycia jednostki imperialnej w oprogramowaniu zewnętrznym, mimo że standardy kodowania NASA w tym czasie upoważniły do korzystania z jednostek metryki. Obliczenia były również wykonywane ręcznie, a nie przy użyciu dostarczonego oprogramowania, ze względu na błędy formatu pliku i różne błędy. Taka sytuacja jest przykładem potrzeby ciągłej integracji.
Eksplorowanie ciągłej integracji
Ciągła integracja to sposób myślenia i strategia zespołu. Oprócz tego autor i prelegent Martin Fowler mówi, że ciągła integracja jest praktyką tworzenia oprogramowania, w której członkowie zespołu często integrują swoją pracę, zwykle każda osoba integruje się co najmniej codziennie — co prowadzi do wielu integracji dziennie.
Każda integracja jest weryfikowana przez zautomatyzowaną kompilację (w tym test), aby jak najszybciej wykryć błędy integracji.
W odpowiednim przypadku takie podejście prowadzi do zmniejszenia problemów z integracją, przechwytując je wcześniej w procesie.
Cele ciągłej integracji to:
- Współpraca z wykorzystaniem
- Włączanie opracowywania równoległego
- Minimalizowanie zadłużenia integracji
- Działanie jako punkt kontrolny jakości
- Zautomatyzuj wszystko!
Uwaga
Zwróć uwagę, jak cele ciągłej integracji obejmują ciągłą współpracę, ciągłe dostarczanie i ciągłą jakość!
Ale co się stanie, gdy nie ma ciągłej integracji? Brak ciągłej integracji może często powodować:
- Długie cykle programowania
- Kod niekompilujący
- W dowolnym momencie kod źródłowy może nie działać
- Kod zawiesza się
- Wysokie błędy kompilacji/ liczba błędów
- Długotrwałe gałęzie powodujące wielodniowe wysiłki scalania
- Brak kodu z kontroli źródła
- Wady zabezpieczeń wykryte pod koniec cyklu programowania
- Duża kwota długu technicznego
- Brak lub niskie numery pokrycia kodu
- Ogólna obniżona jakość
- Ograniczona komunikacja i współpraca
- Kod nie jest zgodne ze standardami kodowania
- Brak lub kilka przeglądów kodu
- Testowanie wykonane pod koniec cyklu programowania
- W wielu przypadkach ręcznie, jeśli w ogóle
Punkty integracji to szybka pętla opinii używana do ulepszania systemu. W przypadku poślizgu czasu punktów integracji projekt jest w tarapatach. Oto, co Dantar Oosterwal mówi o nich w książce The Lean Machine:
Objawieniem punktów integracji jest to, że kontrolują rozwój produktu. Są one punktami dźwigni, aby ulepszyć system. W przypadku poślizgu czasu punktów integracji projekt jest w tarapatach.
Dantar Oosterwal, The Lean Machine
© Scaled Agile, Inc.
Jeśli zastanawiasz się, czy twój zespół naprawdę wykonuje ciągłą integrację, te pytania mogą pomóc w ustaleniu odpowiedzi.
- Czy wszyscy deweloperzy wykonują programowanie oparte na magistrali?
- Czy każda zmiana magistrali rozpoczyna proces kompilacji?
- Czy w przypadku niepowodzenia kompilacji i testowania zespół naprawi kompilację w ciągu kilku minut?
Wydajność ma również wpływ na obecność lub brak ciągłej integracji. Dane zebrane i przeanalizowane w książce The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations by Nicole Forsgren, Jez Humble i Gene Kim pokazują, że gdy niska szybkość rynku rośnie, ich jakość spada.
Ale wysokowydajni mogą utrzymać jakość, jednocześnie zwiększając szybkość rynku. Mają krótsze (i mniej złożone) cykle wdrażania i umożliwiają natychmiastowe korygowanie problemów przy użyciu ciągłej integracji, co zwiększa przepływ i wydajność.
| 2017 | Wysokowydajne wykonawców | Średni wykonawcy | Osoby o niskich wykonawcach |
|---|---|---|---|
| Częstotliwość wdrażania | Wiele dziennie | 1 tydzień — 1 miesiąc | 1 tydzień — 1 miesiąc |
| Czas realizacji zmiany | < 1 godzina | 1 tydzień — 1 miesiąc | 1 tydzień — 1 miesiąc |
| MTTR | < 1 godzina | < 1 dzień | 1 dzień — 1 tydzień |
| Współczynnik niepowodzeń zmian | 0–15% | 0–15% | 31–45% |