Plynulá integrace - Continuous integration

Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Cvičení
Nástroje
Standardy a orgány znalostí
Glosáře
Obrysy

V softwarovém inženýrství je kontinuální integrace ( CI ) spojením pracovních kopií všech vývojářů do sdílené hlavní řady několikrát denně. Grady Booch poprvé navrhl termín CI ve své metodě z roku 1991 , ačkoli neobhajoval integraci několikrát denně. Extreme Programming (XP) přijal koncept CI a zastával integraci více než jednou denně - možná až desítkykrát denně.

Zdůvodnění

Když se pustí do změny, vývojář si vezme kopii aktuální základny kódu, na které bude pracovat. Jelikož ostatní vývojáři odesílají změněný kód do úložiště zdrojového kódu , tato kopie postupně přestane odrážet kód úložiště. Stávající kódová základna se může nejen změnit, ale lze přidat i nový kód a také nové knihovny a další prostředky, které vytvářejí závislosti a potenciální konflikty.

Čím delší vývoj pokračuje na větvi bez sloučení zpět do hlavní řady, tím větší je riziko vícenásobných integračních konfliktů a selhání, když se vývojářská větev nakonec sloučí zpět. Když vývojáři odešlou kód do úložiště, musí nejprve aktualizovat svůj kód, aby odrážel změny v úložišti od doby, kdy převzali svou kopii. Čím více změn úložiště obsahuje, tím více práce musí vývojáři udělat před odesláním vlastních změn.

Nakonec se úložiště může natolik lišit od základních linií vývojářů, že vstoupí do toho, čemu se někdy říká „slučovací peklo“ nebo „integrační peklo“, kde čas potřebný k integraci překračuje čas potřebný k provedení jejich původních změn .

Pracovní toky

Spusťte testy lokálně

CI je určeno k použití v kombinaci s automatizovanými jednotkovými testy napsanými postupy vývoje založeného na testech . To se provádí spuštěním a předáním všech testů jednotek v místním prostředí vývojáře před potvrzením hlavní řady. To pomáhá zabránit tomu, aby nedokončená práce jednoho vývojáře porušila kopii jiného vývojáře. V případě potřeby lze částečně úplné funkce před odevzdáním zakázat, například pomocí přepínačů funkcí .

Kompilace kódu v CI

Server sestavení kompiluje kód pravidelně nebo dokonce po každém potvrzení a hlásí výsledky vývojářům. Použití sestavovacích serverů bylo zavedeno mimo komunitu XP (extrémní programování) a mnoho organizací přijalo CI, aniž by přijalo všechny XP.

Spusťte testy v CI

Kromě automatizovaných testů jednotek organizace využívající CI obvykle používají server sestavení k implementaci kontinuálních procesů uplatňování kontroly kvality obecně - malé úsilí, často aplikované. Kromě spouštění testů jednotky a integrace tyto procesy spouští další statické analýzy, měří a profilují výkon, extrahují a formátují dokumentaci ze zdrojového kódu a usnadňují ruční procesy QA . Na populární službě Travis CI pro open-source testy provádí pouze 58,64% úloh CI.

Tato nepřetržitá aplikace kontroly kvality má za cíl zlepšit kvalitu softwaru a zkrátit dobu potřebnou k jeho dodání tím, že nahradí tradiční postupy uplatňování kontroly kvality po dokončení veškerého vývoje. To je velmi podobné původní myšlence častější integrace, aby integrace byla snazší, pouze u procesů QA.

Nasaďte artefakt z CI

Nyní je CI často propojeno s nepřetržitým doručováním nebo nepřetržitým nasazením v takzvaném kanálu CI/CD. „Nepřetržité doručování“ zajišťuje, že software odhlášený na hlavní lince je vždy ve stavu, který lze nasadit uživatelům, a díky „nepřetržitému nasazení“ je proces nasazení plně automatizovaný.

Dějiny

Nejstarší známá práce na kontinuální integraci byla prostředí Infuse vyvinuté společnostmi GE Kaiser, DE Perry a WM Schell.

V roce 1994 Grady Booch použil frázi kontinuální integrace v Object-Oriented Analysis and Design with Applications (2. vydání), aby vysvětlil, jak při vývoji pomocí mikro procesů „interní vydání představují jakýsi druh kontinuální integrace systému a existují pro vynucení uzavření mikroprocesu “.

V roce 1997 Kent Beck a Ron Jeffries vynalezli extrémní programování (XP) v rámci projektu Chrysler Comprehensive Compensation System , včetně kontinuální integrace. Beck publikoval o kontinuální integraci v roce 1998 a zdůraznil důležitost komunikace tváří v tvář před technologickou podporou. V roce 1999 Beck zpracoval více ve své první plné knize o extrémním programování. CruiseControl , jeden z prvních open-source nástrojů CI, byl vydán v roce 2001.

V roce 2010 Timothy Fitz publikoval článek s podrobnostmi o tom, jak inženýrský tým IMVU vybudoval a používal první praktický systém CI. I když se jeho příspěvek původně setkal se skepticismem, rychle se ujal a našel široké přijetí jako součást metodiky Lean software development , také založené na IMVU.

Běžné postupy

Tato část uvádí osvědčené postupy navržené různými autory, jak dosáhnout kontinuální integrace a jak tuto praxi automatizovat. Automatizace sestavení je sama o sobě osvědčeným postupem.

Nepřetržitá integrace - praxe časté integrace nového nebo změněného kódu do stávajícího úložiště kódu - by se měla vyskytovat dostatečně často, aby mezi potvrzením a sestavením nezůstalo žádné zasahující okno , a aby nemohlo dojít k žádným chybám, aniž by si je vývojáři všimli a okamžitě je opravili. Běžnou praxí je spouštět tato sestavení každým potvrzením do úložiště, nikoli periodicky plánovaným sestavením. Praktičnosti, jak to provést v prostředí rychlého potvrzení pro více vývojářů, jsou takové, že je obvyklé spouštět krátkou dobu po každém potvrzení, poté spustit sestavení, když buď vyprší časovač, nebo po delší době od posledního sestavení . Všimněte si toho, že protože každé nové potvrzení resetuje časovač používaný pro spouštění na krátkou dobu, je to stejná technika, jaká se používá v mnoha algoritmech pro odskakování tlačítek. Tímto způsobem jsou události potvrzení „odstraněny“, aby se předešlo zbytečným stavěním mezi řadou rychlých prověrek. Mnoho automatizovaných nástrojů nabízí toto plánování automaticky.

Dalším faktorem je potřeba systému pro správu verzí, který podporuje atomové potvrzení ; tj. všechny změny vývojáře lze považovat za jedinou operaci potvrzení. Nemá smysl pokoušet se stavět pouze z poloviny změněných souborů.

K dosažení těchto cílů závisí nepřetržitá integrace na následujících zásadách.

Údržba úložiště kódu

Hlavní článek: Kontrola verzí

Tato praxe obhajuje použití systému řízení revizí pro zdrojový kód projektu. Všechny artefakty potřebné k vytvoření projektu by měly být umístěny do úložiště. V této praxi a v komunitě kontroly revizí je konvence, že systém by měl být sestavitelný z nové pokladny a nevyžadoval další závislosti. Obhájce extrémního programování Martin Fowler také uvádí, že tam, kde je větvení podporováno nástroji, by mělo být jeho použití minimalizováno. Místo toho je upřednostňováno, aby byly změny integrovány, než aby bylo zachováno více verzí softwaru současně. Hlavní řada (nebo kufr ) by měla být místem pro pracovní verzi softwaru.

Automatizujte sestavení

Hlavní článek: Automatizace sestavení

Jeden příkaz by měl mít schopnost budovat systém. Mnoho stavebních nástrojů, jako například make , existuje již mnoho let. V prostředích kontinuální integrace se často používají další novější nástroje . Automatizace sestavení by měla zahrnovat automatizaci integrace, která často zahrnuje nasazení do produkčního prostředí . V mnoha případech skript sestavení nejen kompiluje binární soubory, ale také generuje dokumentaci, webové stránky, statistiky a distribuční média (například soubory Debian DEB , Red Hat RPM nebo Windows MSI ).

Proveďte vlastní testování

Jakmile je kód sestaven, měly by proběhnout všechny testy, aby se potvrdilo, že se chová tak, jak vývojáři očekávají, že se bude chovat.

Každý se zavazuje k základní linii každý den

Pravidelným zaváděním může každý zpracovatel snížit počet konfliktních změn. Kontrola práce za týden s sebou nese riziko konfliktu s jinými funkcemi a její řešení může být velmi obtížné. Brzy malé konflikty v oblasti systému způsobí, že členové týmu komunikují o změně, kterou dělají. Provádění všech změn alespoň jednou denně (jednou pro každou vytvořenou funkci) je obecně považováno za součást definice kontinuální integrace. Kromě toho se obecně doporučuje provádět noční sestavení . Toto jsou spodní hranice; očekává se, že typická frekvence bude mnohem vyšší.

Každý závazek (k základní linii) by měl být vytvořen

Systém by měl vytvářet potvrzení pro aktuální pracovní verzi, aby ověřil, že se integrují správně. Běžnou praxí je používat automatickou kontinuální integraci, i když to lze provést ručně. Automatizovaná kontinuální integrace využívá server nebo démona nepřetržité integrace, aby monitoroval změny systému řízení revizí a poté automaticky spustil proces sestavení.

Každé potvrzení opravy chyby by mělo mít testovací případ

Při opravě chyby je vhodné zaslat testovací případ, který chybu reprodukuje. Tím se zabrání tomu, aby byla oprava vrácena a aby se chyba znovu objevila, což je známé jako regrese . Vědci navrhli automatizovat tento úkol: pokud potvrzení opravy chyb neobsahuje testovací případ, lze jej vygenerovat z již existujících testů.

Udržujte stavbu rychlou

Sestavení se musí rychle dokončit, aby v případě problému s integrací bylo rychle identifikováno.

Testujte v klonu produkčního prostředí

Hlavní článek: Testovací prostředí

Mít testovací prostředí může vést k selhání testovaných systémů, když se nasazují v produkčním prostředí, protože produkční prostředí se může od testovacího prostředí výrazně lišit. Vybudování repliky produkčního prostředí je však nákladově náročné. Místo toho by mělo být testovací prostředí nebo oddělené předprodukční prostředí („pracovní“) vytvořeno tak, aby bylo škálovatelnou verzí produkčního prostředí za účelem snížení nákladů při zachování složení a nuancí technologického zásobníku . V těchto testovacích prostředích se virtualizace služeb běžně používá k získání přístupu na vyžádání k závislostem (např. API, aplikace třetích stran, služby, sálové počítače atd.), Které jsou mimo kontrolu týmu, stále se vyvíjejí nebo jsou příliš složité na konfiguraci ve virtuální testovací laboratoři.

Usnadněte si získání nejnovějších dodávek

Zpřístupnění sestavení zúčastněným stranám a testerům může snížit množství nutných přepracování při přestavbě funkce, která nesplňuje požadavky. Počáteční testování navíc snižuje šance, že závady přežijí až do nasazení. Hledání chyb dříve může snížit množství práce nutné k jejich vyřešení.

Všichni programátoři by měli začít den aktualizací projektu z úložiště. Tak zůstanou všichni aktuální.

Každý může vidět výsledky nejnovější verze

Mělo by být snadné zjistit, zda se sestavení rozbije, a pokud ano, kdo provedl příslušnou změnu a jaká tato změna byla.

Automatické nasazení

Většina systémů CI umožňuje spouštění skriptů po dokončení sestavení. Ve většině situací je možné napsat skript pro nasazení aplikace na živý testovací server, na který se může podívat každý. Dalším pokrokem v tomto způsobu myšlení je kontinuální nasazení , které vyžaduje, aby byl software nasazen přímo do výroby, často s dodatečnou automatizací, aby se zabránilo vadám nebo regresím.

Náklady a přínosy

Kontinuální integrace má přinést výhody, jako jsou:

  • Chyby integrace jsou detekovány brzy a lze je snadno dohledat díky malým sadám změn. To šetří čas i peníze po celou dobu životnosti projektu.
  • Vyhne se chaosu na poslední chvíli v datech vydání, kdy se každý pokusí zkontrolovat své mírně nekompatibilní verze
  • Když jednotkové testy selžou nebo se objeví chyba , pokud vývojáři potřebují vrátit kódovou základnu do stavu bez chyb bez ladění , dojde ke ztrátě pouze malého počtu změn (protože integrace se stává často)
  • Neustálá dostupnost „aktuální“ verze pro účely testování, ukázky nebo vydání
  • Častá kontrola kódu tlačí vývojáře k vytváření modulárního, méně složitého kódu

Při nepřetržitém automatizovaném testování mohou výhody zahrnovat:

  • Vynucuje disciplínu častého automatizovaného testování
  • Okamžitá zpětná vazba na dopad místních změn na celý systém
  • Softwarové metriky generované z automatizované testování a CI (například metriky pro pokrytí kódu , složitost kódu , a zahrnuje úplnost ) vývojářům zaměřit na rozvoj funkční, kvalitní kód a pomáhat rozvíjet dynamiku v týmu

Některé nevýhody kontinuální integrace mohou zahrnovat:

  • Sestavení automatizované testovací sady vyžaduje značné množství práce, včetně neustálého úsilí o pokrytí nových funkcí a sledování záměrných úprav kódu.
    • Testování je samo o sobě považováno za nejlepší postup pro vývoj softwaru , bez ohledu na to, zda je či není využívána kontinuální integrace, a automatizace je nedílnou součástí projektových metodik, jako je vývoj řízený testy .
    • Průběžnou integraci lze provádět bez jakéhokoli testovacího balíčku, ale náklady na zajištění kvality při výrobě uvolnitelného produktu mohou být vysoké, pokud to musí být prováděno ručně a často.
  • Tam je nějaká práce spojené zřídit sestavení systému , a to může být složité, takže je obtížné měnit pružně.
  • Kontinuální integrace není nezbytně cenná, pokud je rozsah projektu malý nebo obsahuje netestovatelný starší kód.
  • Přidaná hodnota závisí na kvalitě testů a na tom, jak testovatelný kód skutečně je.
  • Větší týmy znamenají, že do integrační fronty je neustále přidáván nový kód, takže sledování dodávek (při zachování kvality) je obtížné a vytváření front ve frontě může zpomalit každého.
  • S více potvrzeními a sloučeními za den lze snadno odeslat částečný kód funkce, a proto integrační testy selžou, dokud nebude funkce dokončena.
  • Bezpečnost a kritické zajištění vývoje (např. DO-178C , ISO 26262 ) vyžadují přísnou dokumentaci a kontrolu během procesu, které je obtížné dosáhnout pomocí kontinuální integrace. Tento typ životního cyklu často vyžaduje, aby byly před vydáním produktu dokončeny další kroky, kdy je vyžadováno schválení produktu regulačním orgánem.

Viz také

Reference

externí odkazy