Pochopení průběžné integrace a průběžného zavádění

Slyšeli jste CI/CD, ale nejste si jisti, co to je?

V ideálním případě jsou najímáni softwaroví inženýři, aby napsali kód, který je třeba odeslat do produkčního prostředí, aby jej firma, která produkt potřebuje, mohla používat. Pro uspokojení obchodu (často nazývaného uživatelé/klienti) je nezbytné, aby produkty byly bez chyb.

Typickým přístupem softwarových inženýrů je pracovat ve větvích a vytvořit požadavek na stažení, který aktualizuje hlavní větev novou aktualizací, která byla provedena. Přijali jsme praxi psaní testů, abychom zajistili, že nové změny nebudou zavádět chyby. Když vývojáři ve většině případů na funkci pracují, často nevytvoří požadavek na stažení, dokud nejsou s funkcí úplně hotovi. Co se stane, když jsou připraveni, je to;

  • Tráví spoustu času snahou aktualizovat svou kódovou základnu se změnami, ke kterým došlo ve výrobním odvětví, když pracovali.
  • Přitom musí opravit řadu konfliktů při sloučení.
  • Existuje také možnost, že naruší produkční větev, což dále ovlivní ty, kteří se z větve stahují, než bude problém vidět a opraven.

Pokud jste někdy byli v této situaci, budete souhlasit, že to může být utrpení – nikdo dobrovolně nechce trávit svůj pracovní den takto.

Jaké je řešení?

Průběžná integrace

Abychom předešli scénářům, které jsem uvedl výše; inženýrské týmy si mohou osvojit postup zvaný kontinuální integrace – jak název napovídá, jde o nepřetržitou integraci změn kódu provedených vývojáři do sdílené pobočky/úložiště. Kód, který má být integrován, musí projít ověřeným testem, aby se zajistilo, že nenaruší aplikaci. Teprve když test projde, je integrován

  Jak streamovat zvuk z vašeho PC nebo Mac do Chromecastu

Abychom to pochopili, představme si scénář ze skutečného života, kde je tým 10 vývojářů. Tito vývojáři lokálně vytvářejí větev, ve které píší kód pro implementaci určitých funkcí. Namísto odesílání žádostí o stažení, když jsou s funkcí zcela hotovi, se rozhodnou odesílat žádosti o stažení, protože provádějí malé změny. Příkladem takové změny bude vytvoření nového modalu za předpokladu, že vývojář pracuje na funkci, která uživatelům umožňuje spravovat jednotlivé úkoly v aplikaci. Namísto čekání na dokončení funkce úkolu, aby se držel vzor kontinuální integrace, vývojář prosadí tuto malou změnu (ve srovnání s tím, na čem pracuje) a vytvoří požadavek na stažení ke sloučení s kódem.

Než bude tato nová změna integrována, musí proběhnout řada testů.

Týmy softwarového inženýrství využívají nástroje jako Travis CI k vytvoření těchto integračních procesů a testů. S nástroji, jako jsou tyto, jsou testy automatizované, takže se spustí, jakmile je odeslán požadavek na stažení do cílové větve vybrané během nastavení.

Vygenerují se výsledky testů a vývojář, který vytvořil požadavky na stažení, může vidět výsledky a provést potřebné změny. Výhody lpění na tomto vzoru co nejmenší integrace kódu a provedení ověřeného testu jsou;

  • Zapojený tým bude moci vědět, co způsobilo selhání procesu sestavení nebo testu. To snižuje možnost odeslání chyby do výroby.
  • Pokud tým automatizuje proces, bude mít luxus času soustředit se na produktivitu.

Důležitá věc, kterou je třeba v této praxi poznamenat, je, že to povzbuzuje tým, aby často předával kód do hlavní větve. Toto bude neúčinné, pokud ostatní členové týmu nebudou stahovat z hlavní větve, aby aktualizovali své místní úložiště.

Typy testů

Při psaní testů, které budou součástí integračního procesu, uvádíme některé, které lze v procesu implementovat:

  • Integrace – kombinuje jednotlivé jednotky softwaru a testuje je jako skupinu.
  • Jednotka – testuje jednotlivé jednotky nebo součásti softwaru, jako jsou metody nebo funkce.
  • UI – tvrdí, že software funguje dobře z pohledu uživatele.
  • Akceptace – testuje, zda software splňuje obchodní požadavky.
  Maximální počet záložek omezuje otevřené karty v okně [Firefox]

Je důležité poznamenat, že nemusíte testovat všechny, protože několik z nich již může být zahrnuto v kódu napsaném vývojářem.

Nástroje pro kontinuální integraci

Aniž bychom zacházeli do hloubky, zde jsou nástroje, které můžete začít používat ve svých současných nebo nových projektech;

  • Travis CI – známý ve světě open source a slibuje vám, že váš kód hladce otestujete během několika minut.
  • Kruh CI – poskytuje výkon, flexibilitu a ovládání pro automatizaci vašeho potrubí od řízení až po nasazení.
  • Jenkins – poskytuje stovky pluginů pro podporu vytváření, nasazení a automatizace jakéhokoli projektu.

Pokud jste v Jenkinsovi noví, pak bych vám doporučil vzít si toto Kurz Udemy naučit se CI s Java a .NET.

Průběžné nasazení

K čemu to bude dobré, když funkce, kterou vytvoříte, bude ležet v úložišti týdny nebo měsíce, než bude nasazena do produkčního prostředí. Jakkoli mohou inženýrské týmy pracovat na integraci malých změn do hlavní větve, jak se to stane, mohou tyto změny také co nejdříve prosadit do produkčního prostředí.

Cílem při nácviku nepřetržitého nasazení je dostat provedené změny k uživatelům, jakmile je vývojáři integrují do hlavní větve.

Stejně jako v případě průběžné integrace jsou i při využití průběžného nasazení nastaveny automatizované testy a kontroly, aby bylo zajištěno ověření nově integrovaných změn. K nasazení dojde pouze tehdy, když tyto testy projdou.

Aby tým mohl těžit z praxe nepřetržitého nasazení, musí mít zavedené následující;

  • Automatizované testování je základní páteří všech nepřetržitých inženýrských postupů. V případě nepřetržitého zavádění musí kód, který má být nasazen, splňovat standard, který tým zavedl pro to, co hodlá nabídnout koncovým uživatelům. V ideálním případě, pokud je nová změna pod prahovou hodnotou, test by měl selhat a neměl by se integrovat. V opačném případě se integruje.
  • Navzdory tomu, že máme automatizované testy back-to-back, je možné, že některé chyby proklouznou do produkčního prostředí. K tomu je nutné, aby tým byl schopen vrátit zpět provedenou změnu – vrátit zpět nasazení. To by mělo vrátit produkční kód do stavu před provedením nové změny.
  • Monitorovací systémy jsou potřebné pro sledování změn, které byly protlačeny do produkčního prostředí. Takto může být tým schopen sledovat chyby, se kterými se uživatelé setkávají při používání nasazených změn.
  Přeložte lékařský žargon do jednoduché angličtiny pomocí rozšíření pro Chrome

Uvedené nástroje pro průběžnou integraci vám také poskytují funkce pro nastavení systému průběžného nasazení. Je jich spousta, o kterých si také můžete přečíst.

Závěr

Produktivita vývojového týmu je zásadní pro úspěch podnikání. Aby byla zajištěna jejich produktivita, musí být přijaty postupy, které ji podporují. Průběžná integrace a nasazení jsou příklady takových praktik.

Díky nepřetržité integraci mohou týmy denně tlačit co nejvíce kódu. Díky tomu je snadné nasadit nově přidané změny u uživatele co nejdříve. Nasazení těchto změn umožňuje získat zpětnou vazbu od uživatelů. Nakonec bude podnik moci inovovat na základě obdržené zpětné vazby, což je oboustranně výhodné pro všechny.

Můžete se také naučit, jak zvětšit a optimalizovat CI/CD.

Pokud jste vývojář a chcete se naučit CI/CD, podívejte se na toto brilantní kurz.

Užili jste si čtení článku? Co takhle sdílet se světem?