Co je CI/CD – Web Platform – Doka

Zkratka CI/CD znamená Continuous Integration/Continuous Delivery. Jedná se o přístup k vývoji, ve kterém jsou úkoly vytváření, publikování a testování produktu plně nebo částečně automatizovány. Automatizace je velmi často integrována do obchodních procesů produktového týmu nebo společnosti, ale postupy CI/CD lze dokonale implementovat v projektech, které zahrnují pouze jednoho vývojáře.

Jak to pochopit

Kopírovat odkaz „Jak porozumět“ Zkopírováno

Technologie CI/CD začaly aktivně pronikat do procesů vývoje softwaru, když se ukázalo, že agilní postupy jsou dokonale vhodné pro většinu aplikačních programů, o čemž si můžete přečíst více v článku „Metodiky vývoje a agilita“. Ukázalo se, že každou iteraci vývojového cyklu lze urychlit automatizací různých procesů. Typickou iteraci vývojového procesu pomocí CI/CD lze znázornit v následujícím diagramu:

Použití CI/CD se ukázalo jako velmi dobré řešení a brzy se objevily první nástroje. Ve světě webového vývoje jsou to různé „build systems“, „package managers“ a testovací nástroje.

Základní zásady

Kopírovat odkaz “Základní principy” Zkopírováno

Protože mluvíme o integraci a poskytování aplikací spotřebitelům, sada nástrojů úzce souvisí se systémem správy verzí, serverovou infrastrukturou a nástroji pro týmovou spolupráci.

Vývoj a používání CI/CD jsou založeny na následujících principech:

• rozdělení odpovědnosti zúčastněných stran;
• Snížení rizika;
• krátký cyklus zpětné vazby;
• implementace prostředí.

V agilní metodologii zajišťují vývoj aplikací vlastníci produktů, marketéři, návrháři, vývojáři, testeři, infrastrukturní inženýři a uživatelé produktů. Oddělení zájmů znamená, že odpovědnost za různé aspekty produktu spadá do různých rolí. Nástroje CI/CD pomáhají integrovat (automatizovat) všechny procesy interakce mezi nimi.

Například na žádost uživatelů nebo vlastníka produktu designéři vylepšují rozhraní, vývojáři píší kód, opravují chyby a implementují nové funkce. Poté vstoupí do hry testeři a aplikace k nim dorazí ve zkompletované podobě, která prošla všemi potřebnými automatickými kontrolami kvality a správného fungování kódu. Po úspěšném testování uživatelé obdrží produkt připravený k použití, zaznamenají chyby a uvidí, jak lze funkčnost dále rozšířit. Proces se cyklicky opakuje znovu a znovu.

Použití automatizace vývojových procesů snižuje riziko chyb a umožňuje rychle opravit to, co nefunguje. Nastavení nástrojů CI/CD ovlivňuje i takovou část vývoje, jako je vytvoření jednotného prostředí, ve kterém probíhá vývoj softwarového produktu. To je pro vývojáře nesmírně důležité.

Například použití stejných balíčků npm, jejich verzí a testovacích nástrojů umožňuje vyvíjet aplikaci podle jednotných standardů kvality. Náhodné chyby způsobené nesprávným prostředím nebo jiným operačním systémem jsou prakticky vyloučeny.

Etapy integrace a dodání aplikace

Kopírovat odkaz “Fáze integrace a dodání aplikace” Zkopírováno

Provoz nástrojového systému CI/CD je založen na cykličnosti, která dokonale zapadá do rámce agilní metodiky vývoje softwaru. Cyklus aplikace nástroje se skládá z následujících fází:

• psaní kódu;
• shromáždění;
• ruční testování;
• uvolnění;
• nasazení;
• podpora a monitorování;
• plánování.

Psaní kódu

Kopírovat odkaz “Zápis kódu” Zkopírováno

V této fázi je nejdůležitějším nástrojem systém správy verzí. Obvykle je to Git. Důležitým prvkem je zde model větvení, tedy principy používání větví ve vývoji. Například projekty na GitHubu obvykle používají model větvení GitHub Flow:

1. Vývojář rozdělí úložiště na svůj účet GitHub nebo naklonuje úložiště do svého počítače. Fork je kompletní kopie (zrcadlení) úložiště v určitém okamžiku, kterou lze v případě potřeby aktualizovat.
2. Vývojář poté provede změny na rozvětvení nebo místní kopii. Je dobrou praxí vytvořit novou větev a pracovat na ní.
3. Poté se vytvoří pull request – to je požadavek na sloučení s hlavní větví.
4. Žádost o stažení vám umožní zkontrolovat všechny navrhované změny, diskutovat o řešeních a dosáhnout konsensu.
5. Jakmile jsou všechny změny schváleny, jsou sloučeny do hlavní větve úložiště.

Existují i ​​další modely větvení, jako je Git-flow, který je dobře popsán v článku „Úspěšný model větvení Git“ v angličtině a přeložený do ruštiny „Úspěšný model větvení pro Git“.

shromáždění

Kopírovat odkaz “Sestava” Zkopírováno

Po zápisu a počátečním testování na lokálním počítači vývojáře je kód odeslán na server a zkompilován. Testovací sestavení nebo sestavení připravené k publikování je nakonfigurováno a spuštěno na serveru. V poslední době se ke stavění stále častěji používají kontejnery, jako jsou kontejnery Docker. Více si o nich můžete přečíst v sérii článků o Dockeru:

• Co je Docker;
• Jak Dockerfile funguje;
• Správa dat v Dockeru;
• Vícekontejnerová aplikace a Docker Compose.

K automatizaci montáže lze použít různé systémy. Nejoblíbenější z nich jsou:

• Jenkins;
• Akce GitHubu;
• GitLab CI/CD;
• Bitbucket potrubí;
• JetBrains TeamCity.

Sestavení je podporováno oblíbenými a specializovanými hostingovými službami, jako je Netlify.

Testování

Kopírovat odkaz “Testování” Zkopírováno

Po počáteční přípravě kódu je produktu přiřazena verze budoucího vydání s číslem testovacího sestavení pro podrobné automatické a manuální testování. Například, pokud číslo budoucího vydání v.2.4.5, pak lze číslo prvního testovacího sestavení zadat takto: v.2.4.5-1. V této fázi převažuje manuální testování produktu, hledání a plánování oprav chyb. Po několika iteracích je produkt považován za připravený k vydání a přechází do další fáze testování.

V této fázi jsou široce používány integrační testy, E2E testy, manuální a automatizované UI/UX testování. K tomu lze použít různé nástroje. Jest může například pokrýt úkoly unit, integrace a E2E testování webové aplikace. Chcete-li vytvořit snímky obrazovky webové aplikace a automaticky je porovnat s benchmarkem, můžete použít Selenium nebo Puppeteer. V tomto případě můžete nejen simulovat načítání webové aplikace a ukládat snímky obrazovek různých velikostí, ale také pomocí scénářů zjistit, jak bude budoucí uživatel s aplikací pracovat.

Uvolnění

Kopírovat odkaz “Uvolnění” Zkopírováno

Existují různé typy cyklů vydání, které jsou podrobně popsány v článku Metodiky vývoje a agilita. V závislosti na vlastnostech produktu, složení týmu a úkolech vlastníka produktu se určuje frekvence vydání. Důležité není jen samotné vydání, ale také to, jak tým pracoval na další fázi.

Nástroje CI/CD jsou v této fázi zodpovědné především za sběr různých statistických informací. Mohou to být buď uživatelské metriky (například Yandex.Metrica nebo Google Analytics), nebo metriky přijaté v rámci týmu ke sledování efektivity konkrétního člena týmu (můžete například sledovat počet dokončených úkolů, rychlost jejich dokončení, iniciativu a profesní růst pomocí vestavěných nástrojů Jira, Wrike nebo Trello).

Rozvinutí

Zkopírujte odkaz “Rozmístění” Zkopírováno

Začíná fáze dodání produktu koncovým spotřebitelům. Složitost nasazení produktu souvisí se složitostí infrastruktury (s architekturou konstrukce serveru, různými optimalizacemi načítání a provozu aplikací, cachováním). Jednoduché webové aplikace nevyžadují zvláštní pozornost z hlediska infrastruktury. Existují ale velké internetové obchody, vyhledávače, streamovací služby, pro které mohou být infrastrukturní úkoly z pohledu konkurence na trhu téměř nejdůležitější.

Podpora a sledování

Kopírovat odkaz “Podpora a monitorování” Zkopírováno

Konečně je aplikace dostupná i pro běžné uživatele. Důležitá je zde rychlost a přesnost odpovědí na dotazy uživatelů (tj. organizace služby uživatelské podpory) a dobře integrovaná a kompetentní marketingová politika. K řešení těchto problémů je k dispozici mnoho nástrojů, ale nebudeme se o nich podrobně věnovat, protože nesouvisejí s vývojem. Tyto nástroje se v zásadě příliš neliší od nástrojů pro běžnou kancelářskou práci v rámci velké společnosti (IP telefonie, chaty, email, různé task managery, příprava automatických reportů a další softwarové a hardwarové nástroje). K podpoře moderních produktů se často používají hlasoví asistenti a chatboti. Téměř všechny tyto nástroje nejsou nástroje CI/CD, ale téměř vždy poskytují rozhraní API, takže lze nastavit hlubokou integraci mezi různými fázemi a zlepšit tak kvalitu produktu.

Plánování

Kopírovat odkaz “Plánování” Zkopírováno

Důležitou fází je také plánování dalšího cyklu. Na základě uživatelských zkušeností se tvoří nevyřízené úkoly pro implementaci, jsou přiřazeny priority a interpreti. Poté se cyklus CI/CD uzavře.

Je důležité si uvědomit, že některé kroky CI/CD lze upravit nebo úplně přeskočit. Konkrétní detaily závisí na konkrétním produktu, složení a kvalifikaci týmu a specifikách uvedení produktu na trh.

Výhody a nevýhody

Kopírovat odkaz “Výhody a nevýhody” Zkopírováno

• Nástroje CI/CD umožňují rychle uvést softwarový produkt na trh, opravit chyby a implementovat nové funkce.
• Automatizace snižuje zátěž členů týmu, usnadňuje testování a snižuje počet chyb v každé iteraci. Hlavní výhodou je rychlá zpětná vazba.
• Flexibilní plán umožňuje rychle přerozdělit týmové zdroje k řešení skutečně důležitých úkolů.

• Nástroje CI/CD jsou často vnímány jako švýcarský armádní nůž, který zvládne jakýkoli úkol. Pokud chybí zkušenosti, může to vést k výrazné komplikaci procesů v týmu.
• Nástroje CI/CD nemohou vyřešit problémy interakce v týmu; vše se bude muset dohodnout.
• Všichni členové týmu musí pracovat v jediném ekosystému.

На практике

Kopírovat odkaz “V praxi” Zkopírováno

Vitalij Baev radí

Kopírovat odkaz „Vitaliy Baev radí“ Zkopírováno

Při instalaci závislostí pomocí správce balíčků v automatizovaném prostředí CI/CD se ujistěte, že používáte volbu potvrzení souboru zámku. Takto to vypadá pro různé správce balíčků:

# npmnpm install # ❌npm ci # ✅ # pnpmpnpm install # ❌pnpm install --frozen-lockfile # ✅ # yarn classicyarn install # ❌yarn install --frozen-lockfile # ✅ # yarn modernyarn install # ❌yarn install --immutable # ✅ # npm npm install # ❌ npm ci # ✅ # pnpm pnpm install # ❌ pnpm install --frozen-lockfile # ✅ # yarn classic yarn install # ❌ yarn install --frozen-lockfile # ✅ # yarn modern yarn install # ❌ yarn install --immutable # ✅   Kopírovat Zkopírováno Kopírování se nezdařilo   

Bez těchto příkazů existuje šance na instalaci závislostí jiných verzí, než které jsou uvedeny v souboru zámku. To může způsobit jemné chyby související s verzemi knihoven.

Pokud například soubor zámku neobsahuje závislost uvedenou v balíček.json. Standardní instalace aktualizuje soubor zámku, ale instalace v režimu CI selže s chybou.

Stojí za zmínku, že moderní správci balíčků pnpm a Yarn povolují tento režim ve výchozím nastavení, pokud instalace probíhá v prostředí CI/CD.

Více o práci se správcem balíčků a mechanismem zamykacích souborů si můžete přečíst v článku „Správci balíčků“.