Analýza kontinuální integrace

  • 4 min

Kontinuální integrace je jednou z osmi funkcí v taxonomii DevOps.

Zjištění, proč je nutná kontinuální integrace

23. září 1999, Mars Climate Orbiter vytáhl své solární pole, aby je chránil před dočasným sestupem do horní martské atmosféry.

Po úspěšném vstupu do oběžné dráhy měl satelit několik let přenášet fotky Marsu na Zemi. Ale bohužel, řemeslo vyhořelo v martské atmosféře.

Chyba v softwaru pro řízení země, která byla dodána třetí stranou, vypočítala hodnotu v císařské jednotce v libry-sekundách. Software vytvořený NASA očekával, že hodnota bude v metrické jednotce newton-sekund. Vzhledem k tomu, že tyto hodnoty nebyly správně převedeny, byly malé nesrovnalosti v pozici vesmírné lodi složeny v průběhu milionů mil.

Kontrola kvality si nevšimla použití císařské jednotky v externím softwaru, i když standardy kódování NASA v době použití jednotek metrik. Výpočty se také prováděly ručně místo použití dodaného softwaru kvůli chybám formátu souborů a různým chybám. Tato situace je příkladem potřeby kontinuální integrace.

Prozkoumání kontinuální integrace

Kontinuální integrace je myšlení a týmová strategie. Kromě toho autor a mluvčí Martin Fowler říká, že kontinuální integrace je praxe vývoje softwaru, kde členové týmu často integrují svou práci, obvykle každý člověk integruje alespoň denně – což vede k více integrací za den.

Každá integrace je ověřená automatizovaným sestavením (včetně testu), aby co nejrychleji detekovali chyby integrace.

Když to uděláte správně, tento přístup vede ke snížení problémů s integrací tím, že je zachytí dříve v procesu.

Diagram shows the difference between continuous delivery and continuous deployment. The stages are the same in both cases: code done - unit tests - integrate - acceptance test - deploy to production. For continuous delivery, deployment to production happens manually. For continuous deployment, it's automatic. Continuous integration spans the first three stages for both continuous delivery and continuous deployment.

Cílem kontinuální integrace je:

Poznámka:

Všimněte si, jak cíle kontinuální integrace zahrnují průběžnou spolupráci, průběžné doručování a průběžnou kvalitu!

Co se ale stane, když neexistuje žádná kontinuální integrace? Nedostatek průběžné integrace může často vést k tomu, že:

  • Dlouhé vývojové cykly
    • Nekopilující kód
    • V jakémkoli okamžiku nemusí být zdrojový kód funkční.
    • Kód se zablokuje.
  • Vysoká selhání sestavení / Počty chyb
    • Dlouhé živé větve, což způsobuje vícedenní slučování
    • Chybějící kód ve správě zdrojového kódu
    • Chyby zabezpečení zjištěné v pozdní fázi vývojového cyklu
    • Velké množství technického dluhu
    • Nečísla pokrytí kódu nebo s nízkými čísly pokrytí
    • Celková nižší kvalita
  • Omezená komunikace a spolupráce
    • Kód, který nesloučuje standardy kódování
    • Ne nebo několik recenzí kódu
    • Testování dokončené v pozdní fázi vývojového cyklu
    • V mnoha případech ručně, pokud vůbec

Integrační body jsou rychlá smyčka zpětné vazby, která se používá ke zlepšení systému. Při vypršení časování integračních bodů je projekt v potížích. Zde je, co Dantar Oosterwal říká o nich v knize Štíhlý stroj:

Epiphany integračních bodů je, že řídí vývoj produktů. Jsou to body využití ke zlepšení systému. Při vypršení časování integračních bodů je projekt v potížích.

Dantar Oosterwal, štíhlý stroj

© Scaled Agile, Inc.

Pokud vás zajímá, jestli váš tým skutečně provádí kontinuální integraci, tyto otázky vám můžou pomoct určit odpověď.

  • Dělají všichni vývojáři vývoj založený na kmenech?
  • Zahájí každá změna kmene proces sestavení?
  • Když sestavení a testování selže, opraví tým sestavení během několika minut?

Na výkon má vliv také přítomnost nebo absence kontinuální integrace. Data shromážděná a analyzovaná pro knihu The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations by Nicole Forsgren, Jez Humble a Gene Kim ukazují, že když se zvýší rychlost nízkého výkonu na trhu, jejich kvalita se sníží.

Ale vysoce výkonné můžou zachovat kvalitu a zároveň zvýšit rychlost uvedení na trh. Mají kratší (a méně složité) cykly nasazení a používají kontinuální integraci k okamžité nápravě problémů, zvýšení toku a efektivity.

2017 Vysoce výkonné Střední účinkující Nízké výkony
Frekvence nasazení Násobek za den 1 týden – 1 měsíc 1 týden – 1 měsíc
Předstih pro změnu < 1 hodina 1 týden – 1 měsíc 1 týden – 1 měsíc
MTTR < 1 hodina < 1 den 1 den – 1 týden
Změna četnosti selhání 0-15% 0-15% 31-45%