Použití systémů softwarového inženýrství

Jakmile porozumíte problémům, které chcete řešit jako první na cestě k vytváření platformy, může se vylepšení samoobslužné služby pro vývojáře dostat na začátek seznamu. Jedním z nejjednodušších způsobů, jak začít s povolením automatizovaných samoobslužných prostředí, je opakované použití stávajících technických systémů. Tyto systémy budou nejen známé pro vás a vaše interní zákazníky, ale můžou vám i vašim interním zákazníkům umožnit širokou škálu scénářů automatizace, i když počáteční uživatelské prostředí nebude hezké.

Tento článek obsahuje několik tipů pro použití technických systémů k řešení širší škály samoobslužných scénářů a toho, jak můžete zapouzdřovat osvědčené postupy do šablon, které vám pomůžou začít správně a zůstat v pořádku.

Vyhodnocení základních postupů DevOps a DevSecOps

Technické systémy jsou důležitým aspektem vaší interní vývojářské platformy. Pokud ale ještě nemáte žádné systémy, které by cílily alespoň na některé z hlavních tenantů DevOps a DevSecOps, problémy, které identifikujete, vám pravděpodobně pomůžou začít tam. Z nich se vytvářejí interní vývojářské platformy, aby se snížila kognitivní zátěž pro všechny zúčastněné.

Abychom to zrekapitulovali, DevOps kombinuje vývoj a operace, aby spojil lidi, procesy a technologie při plánování, vývoji, doručování a provozu aplikací. Jejím cílem je zlepšit spolupráci mezi historicky jednotlivými rolemi, jako je vývoj, provoz IT, kvalitní inženýrství a zabezpečení. Vytvoříte nepřetržitou smyčku mezi vývojem, nasazením, monitorováním, pozorováním a zpětnou vazbou. DevSecOps se v této smyčce vrství s postupy nepřetržitého zabezpečení v celém procesu vývoje aplikací.

Centrum prostředků DevOps od Microsoftu je skvělým místem, kde můžete hledat rady ohledně typů procesů a systémů, které budete potřebovat, takže je nebudeme v této části podrobně probít. Tyto složky se stávají základními složkami, jak se posunete vpřed. A nezapomeňte do svých plánů zahrnout nedávná témata DevSecOps, jako je zabezpečení dodavatelského řetězce kontejnerů .

Další informace o nepřetržité zpětné vazbě najdete v tématu Metriky, které je potřeba zvážit. Další informace o nástrojích pro použití v oblastech pozorovatelnosti, monitorování a nepřetržité zpětné vazby najdete v článku Upřesnění platformy aplikace.

Ve zbývající části tohoto článku se zaměříme na vylepšení, která jsou příměji přisuzována přesunu techniky platformy: zpevněné cesty, automatizované zřizování infrastruktury (kromě nasazení aplikací), nastavení prostředí kódování, samoobslužné zřizování a konfigurace nástrojů, týmových prostředků a služeb, které nejsou přímo součástí smyčky vývoje aplikací.

Vytvoření požadovaných zpevněných cest

Pokud už máte několik sad nástrojů, které tvoří vaše technické systémy, musíte se nejdříve rozhodnout, jestli se chcete rozhodnout, jestli je chcete konsolidovat v rámci počátečního úsilí o vytváření platformy, nebo jestli budete od samého počátku podporovat souhvězdí různých nástrojů. Ve většině případů je nejúčinnější definovat sadu zpevněných cest v rámci tohoto souhvězdí nástrojů a poskytuje vyšší úroveň flexibility.

Když se začnete posouvat směrem k produktovému myšlení, můžete si technické systémy v rámci těchto zpevněných cest představit jako nástroje, které se spravují centrálně jako služba vývojovým týmům. Jednotlivé týmy nebo divize ve vaší organizaci se pak mohou odchýlit, ale očekává se, že budou spravovat, udržovat a platit za své nástroje odděleně, a přitom budou dodržovat všechny požadavky na dodržování předpisů. To poskytuje způsob, jak do ekosystému vložit nové nástroje bez přerušení, protože můžete vyhodnotit vše, co se odchyluje od možného zahrnutí do zpevněné cesty v průběhu času. Jeden technický vedoucí platformy to vyložil takto:

Pořád můžete dělat vlastní věci, ale dělejte to směrem, kterým jdeme... můžete změnit, co chcete, ale to se stane vaší zodpovědností. Vy vlastníte změny - vlastníte ostré nože. - Mark, vedoucí pro inženýry platforem, Velká evropská nadnárodní maloobchodní společnost

Vzhledem k tomu, že klíčovým cílem pro vytváření platforem je přechod k produktovému myšlení, kde poskytujete hodnotu interním zákazníkům, funguje tento přístup k souhvězdí obvykle lépe než požadavek shora dolů. Když vytváříte a vylepšujete zpevněné cesty, ponechání určité flexibility umožňuje týmům poskytovat vstupy a řešit všechny skutečně jedinečné požadavky pro danou aplikaci, aniž by to mělo vliv na ostatní v organizaci. To vede k souboru plně zpevněných zlatých cest, zatímco jiné jsou pouze částečně dlážděné. V případech, kdy neexistují žádné jedinečné požadavky, týmy vývojářů navíc přirozeně způsobí, že budou chtít přejít na podporovanou cestu v průběhu času.

Pokud dáváte přednost strategii konsolidace, mějte na paměti, že migrace stávajících aplikací může být pracnější, než očekáváte, takže pokud chcete začít, budete se pravděpodobně chtít zaměřit na správný počáteční aspekt tohoto prostoru a zaměřit se na nové projekty. To vám poskytne první zpevněnou cestu, zatímco všechno, co existuje, je ze své podstaty nezpevněné. Vývojové týmy na nezpevněné cestě pak zváží přesun, jakmile nová zpevněná cesta ukáže svou hodnotu pro organizaci. V tomto okamžiku můžete spustit kampaň Get Right, která zajistí, aby se všichni dostali do požadovaného stavu prostřednictvím obousměrné komunikace, protože vývojové týmy to považují za výhodu, nikoli jako daň. Během kampaně se týmy inženýrů platforem mohou zaměřit na pomoc týmům s migrací, zatímco vývojové týmy poskytují zpětnou vazbu, jak vylepšit zpevněné cesty.

Bez ohledu na to se snažte vyhnout použití zpevněných cest. Nejúčinnějším způsobem, jak je zavést, je zdůraznit, co z nich týmy dostanou, a ne vynuceným přijetím. Vzhledem k tomu, že se vaše interní vývojářská platforma zaměřuje na to, aby tyto týmy byly šťastné, je rozpočet a čas-to-value tlak na jednotlivé vedoucí pracovníky obvykle postará o zbytek. Získejte správné kampaně a pak poskytují cestu pro obousměrnou konverzaci, která je nejlepší pro ty, kteří jsou na nezblokované cestě, jak přepnout.

Vylepšení samoobslužných služeb pro zpevněné cesty pomocí nástrojů pro automatizaci pro vývojáře

Součástí vytváření první zpevněné cesty by mělo být vytvoření základních produktů pro automatizaci pro vývojáře. Ty jsou důležité, když začnete přemýšlet o povolení samoobslužných funkcí pro vývojáře.

Povolení automatického zřizování infrastruktury aplikací během průběžného doručování

Pokud ještě nejsou implementované, problémy, které jste identifikovali během plánování, budou pravděpodobně odkazovat na problémy, které vám může pomoct vyřešit kontinuální integrace (CI) a průběžné doručování (CD). V této oblasti existují produkty, jako jsou GitHub Actions, Azure DevOps, Jenkins, společně s řešeními GitOps založenými na vyžádání, jako je Flux nebo Argo CD. S těmito tématy můžete začít v Centru prostředků Microsoft DevOps.

I když jste už implementovali způsob průběžného nasazování aplikace ve stávající infrastruktuře, měli byste také zvážit použití infrastruktury jako kódu (IaC) k vytvoření nebo aktualizaci potřebné infrastruktury aplikace jako součásti kanálu CD.

Podívejte se například na tyto ilustrace, které znázorňují dva přístupy, které používají GitHub Actions k aktualizaci infrastruktury a nasazení do Azure Kubernetes Service: jeden používá nasazení založená na nabízených oznámeních a druhá nasazení založená na vyžádání (GitOps).

Další informace o jednotlivých přístupech najdete v tématu CI/CD pro aplikace AKS s GitHub Actions a Gitflow.

To, co zvolíte, se často řídí vaší stávající sadou dovedností IaC a podrobnostmi o cílové platformě aplikace. Přístup GitOps je novější a je oblíbený v organizacích, které používají Kubernetes jako základ svých aplikací, zatímco model založený na přijetí změn v současné době poskytuje největší flexibilitu vzhledem k počtu dostupných možností. Očekáváme, že většina organizací bude používat kombinaci těchto dvou možností. Bez ohledu na to vám znalosti postupů IaC pomůžou naučit se vzorům, které platí pro další scénáře automatizace.

Centralizace IaC v katalogu nebo registru za účelem škálování a zlepšení zabezpečení

Pokud chcete spravovat a škálovat IaC napříč aplikacemi, měli byste artefakty IaC publikovat centrálně pro opakované použití. Můžete například použít moduly Terraformu v registru, moduly Bicep, recepty Radius nebo Charty Helm uložené v registru artefaktů OCI nativním pro cloud, jako je Azure Container Registry (ACR) nebo DockerHub nebo katalog v prostředích nasazení Azure (ADE). V případě GitOps a Kubernetes vám rozhraní API clusteru (a implementace jako CAPZ) umožňuje spravovat clustery úloh Kubernetes, zatímco vlastní definice prostředků, jako je operátor služby Azure , můžou poskytovat přidanou podporu pro další druhy prostředků Azure, další nástroje, jako je podpora prostředků mezi rovinami napříč několika cloudy. Ty umožňují používat centralizované nebo běžné charty Helm v podobně jako ACR pro širší škálu scénářů.

Centralizace IaC zlepšuje zabezpečení tím, že poskytuje lepší kontrolu nad tím, kdo může provádět aktualizace, protože už nejsou uložené v kódu aplikace. Při aktualizaci kódu, kdy odborníci, provozní pracovníci nebo technici platformy udělují potřebné změny, existuje menší riziko náhodného přerušení způsobeného neúmyslnou změnou. Tyto stavební bloky těží také vývojáři, protože nemusí sami vytvářet kompletní šablony IaC a automaticky využívat zakódované osvědčené postupy.

Formát IaC, který zvolíte, závisí na vaší stávající sadě dovedností, úrovni potřebné kontroly a modelu aplikace, který používáte. Například Azure Container Apps (ACA) a nedávný experimentální projekt inkubace operačního systému Radius mají větší názor než přímé použití Kubernetes, ale také zjednodušují prostředí pro vývojáře. Trénovací modul Popis typů cloudových služeb vám pomůže pochopit výhody a nevýhody různých modelů. Bez ohledu na to má odkazování na centralizované a spravované IaC místo úplných definic ve zdrojovém stromu významné výhody.

Zachování všech potřebných identit nebo tajných kódů tak, aby k nim vývojáři nemohli přímo přistupovat v základních stavebních blocích pro zásady správného řízení. Podívejte se například na tento obrázek oddělení rolí, které můžete dosáhnout pomocí prostředí azure deployment environment (ADE).

Tady inženýři platforem a další odborníci vyvíjejí IaC a další šablony a umisťují je do katalogu. Operace pak můžou přidávat spravované identity a předplatná podle typu prostředí a přiřazovat vývojáře a další uživatele, kteří je můžou používat ke zřizování.

Vývojáři nebo váš kanál CI/CD pak můžou pomocí Azure CLI nebo Azure Developer CLI zřídit předkonfigurovanou a řízenou infrastrukturu, aniž by museli mít přístup k podkladovému předplatnému nebo identitám, které k tomu jsou potřeba. Ať už používáte něco jako ADE, nebo ne, váš zvolený systém průběžného doručování vám může pomoct bezpečně aktualizovat infrastrukturu tím, že oddělí tajné kódy a bude odebírat obsah IaC od umístění, která vývojáři nemůžou sami zpřístupnit nebo upravovat.

Povolení samoobslužné služby ve scénářích nad rámec průběžného doručování aplikací

I když koncepty CI a CD souvisejí s vývojem aplikací, mnoho věcí, které interní zákazníci chtějí zřídit, není přímo svázaná s konkrétní aplikací. Může to být sdílená infrastruktura, vytvoření úložiště, nástroje pro zřizování a další.

Pokud chcete zjistit, kde by to mohlo pomoct, zamyslete se nad tím, kde aktuálně máte ruční nebo servisní procesy. U každého z nich se zamyslete nad těmito otázkami:

• Jak často k tomuto procesu dochází?
• Je proces pomalý, náchylný k chybám nebo jeho dosažení vyžaduje značné množství práce?
• Jsou tyto procesy ruční kvůli požadovanému kroku schválení, nebo jednoduše kvůli nedostatečné automatizaci?
• Pokud potřebujete schvalovatele, znají systémy správy zdrojového kódu a procesy žádostí o přijetí změn?
• Jaké jsou požadavky na auditování procesů? Liší se tyto požadavky od požadavků na auditování systému správy zdrojového kódu?
• Existují procesy, se kterými můžete začít, s nižším rizikem, než přejdete na složitější?

Jako potenciální cíle k automatizaci nejprve identifikujte časté procesy, procesy s vysokým úsilím nebo náchylné k chybám. Dále si probereme několik jednoduchých způsobů, jak to udělat.

Použití všeho jako vzoru kódu

Jednou z pěkných věcí na gitu kromě jeho všudypřítomnosti je, že má být bezpečným a auditovatelným zdrojem informací. Kromě historie potvrzení a řízení přístupu poskytují koncepty, jako jsou žádosti o přijetí změn a ochrana větví, způsob, jak vytvořit konkrétní revidující, historii konverzací nebo automatizované kontroly, které musí proběhnout před sloučením do hlavní větve. V kombinaci s flexibilními moduly úloh, jako jsou ty, které se nacházejí v systémech CI/CD, máte zabezpečenou architekturu automatizace.

Myšlenka, která je za vším jako kódem, spočívá v tom, že v zabezpečeném úložišti Git můžete převést téměř cokoli na soubor. Obsah pak můžou číst různé nástroje nebo agenti připojení k úložišti. Zacházení se vším jako s kódem pomáhá opakovatelnost prostřednictvím šablon a zjednodušuje samoobslužnou službu pro vývojáře. Pojďme si projít několik příkladů, jak to může fungovat.

Použití vzorů IaC na libovolnou infrastrukturu

I když IaC získalo popularitu pro automatizaci doručování aplikací, tento model se vztahuje na všechny infrastruktury, nástroje nebo služby, které byste mohli chtít zřídit a konfigurovat – nejen na ty, které jsou vázané na konkrétní aplikaci. Můžete například sdílet K8s s clustery s nainstalovaným fluxem, zřizovat něco jako DataDog , který používá více týmů a aplikací, nebo dokonce nastavit oblíbené nástroje pro spolupráci.

Funguje to tak, že máte samostatné zabezpečené centralizované úložiště, které obsahuje řadu souborů, které představují to, co by se mělo zřídit a nakonfigurovat (v tomto případě cokoli od Bicep, Terraformu až po charty Helm a další nativní formáty Kubernetes). Úložiště vlastní provozní tým nebo jiná skupina správců a vývojáři (nebo systémy) můžou odesílat žádosti o přijetí změn. Jakmile tito správci tyto žádosti o přijetí změn sloučí do hlavní větve, můžou se ke zpracování změn hodit stejné nástroje CI/CD, které se používají při vývoji aplikací. Podívejte se na tento obrázek, který používá identity GitHub Actions a IaC a nasazení v prostředích pro nasazení Azure:

Pokud už k nasazení aplikací používáte přístup GitOps , můžete znovu použít i tyto nástroje. Kombinace nástrojů, jako je Flux a Azure Service Operator , umožňuje rozšíření mimo Kubernetes:

V obou případech máte plně spravovaný, reprodukovatelný a auditovatelný zdroj informací – i když to, co se vygeneruje, není určené pro aplikaci. Stejně jako při vývoji aplikací je možné všechny tajné kódy nebo spravované identity, které potřebujete, ukládat v modulu kanálu nebo pracovního postupu nebo v nativních funkcích služby zřizování.

Vzhledem k tomu, že lidé vytvářející žádosti o přijetí změn nebudou mít přímý přístup k těmto tajným kódům, poskytuje vývojářům způsob, jak bezpečně spouštět akce, ke kterým nemají přímé oprávnění. To vám umožní dodržovat princip nejnižších oprávnění a zároveň vývojářům poskytnout samoobslužnou možnost.

Sledování zřízené infrastruktury

Až začnete tento přístup škálovat, zamyslete se nad tím, jak chcete sledovat zřízenou infrastrukturu. Vaše úložiště Git je zdrojem pravdivých informací o konfiguraci, ale nesděluje konkrétní identifikátory URI a informace o stavu toho, co jste vytvořili. Přístup typu vše jako kód vám ale poskytne zdroj informací, které můžete využít k syntetizaci inventáře zřízené infrastruktury. Dobrým zdrojem těchto informací, ke kterým se můžete připojit, může být také zřizovací služba. Například prostředí pro nasazení Azure zahrnují funkce sledování prostředí, o kterých mají vývojáři přehled.

Další informace o sledování napříč různými zdroji dat najdete v tématu Návrh vývojářské samoobslužné základny.

Použití zabezpečení jako kódu a zásady jako vzorů kódu

Zřizování infrastruktury je sice užitečné, ale stejně důležité je zajistit, aby tato prostředí byla zabezpečená a obecně dodržovala zásady vaší organizace. To vedlo ke vzniku konceptu "zásady jako kódu". Konfigurační soubory v úložišti správy zdrojového kódu se tady dají použít k akcím, jako je kontrola zabezpečení jednotek nebo použití zásad infrastruktury.

Tento přístup podporuje mnoho různých produktů a open source projektů, mezi které patří mimo jiné Azure Policy, Open Policy Agent, GitHub Advanced Security a GitHub CODEOWNERS. Při výběru aplikační infrastruktury, služeb nebo nástrojů nezapomeňte vyhodnotit, jak dobře podporují tyto vzory. Další informace o zpřesnění aplikace a zásad správného řízení najdete v tématu Upřesnění aplikační platformy.

Použití všeho jako kódu pro vlastní scénáře

Všechno jako kód rozšiřuje tyto vzory na širokou škálu úloh automatizace a konfigurace nad rámec IaC. Podporuje nejen vytváření nebo konfiguraci jakéhokoli typu infrastruktury, ale také aktualizaci dat nebo spouštění pracovních postupů v libovolném podřízeného systému.

Žádost o přijetí změn se stává dobrým výchozím samoobslužným prostředím pro různé procesy – zejména když začínáte. Procesy přirozeně získají výhody zabezpečení, auditovatelnosti a vrácení zpět, které git sám poskytuje, a systémy, kterých se to v průběhu času může měnit, aniž by to mělo vliv na uživatelské prostředí.

Teams jako kód

Jedním z příkladů použití všeho jako kódu na vlastní scénáře jsou týmy jako vzor kódu. Organizace tento model používají ke standardizaci členství v týmu a v některých případech oprávnění vývojářských nástrojů a služeb napříč širokou škálou systémů. Tento model eliminuje ruční onboarding a offboarding procesů oddělení služeb, které jsou založené na potřebě vývojářů a operátorů systémů přistupovat ke svým vlastním konceptům seskupení, uživatelů a přístupu. Ruční servisní procesy jsou potenciálním bezpečnostním rizikem, protože je možné nadměrně nastavit přístup. Při použití týmů jako vzoru kódu může kombinace gitu a žádostí o přijetí změn umožnit samoobslužnou službu z auditovatelného zdroje dat.

Příklad vyspělé a rozsáhlé varianty tohoto modelu najdete v blogovém příspěvku GitHubu o správě nároků. GitHub také nabízí opensourcovou sofistikovanou implementaci Entitlements , kterou můžete vyzkoušet nebo přijmout. I když blogový příspěvek popisuje nároky všech zaměstnanců, můžete týmy použít jako koncept kódu na scénáře s užším oborem vývojových týmů. Tyto vývojové týmy nemusí být v organizačním diagramu zaměstnanců vůbec zastoupeny a zahrnují vlastní nástroje nebo služby, které můžou členům týmu komplikovat onboarding nebo offboarding.

Tady je souhrn zjednodušené varianty této myšlenky, která ke koordinaci aktualizací využívá systém CI/CD a skupiny zprostředkovatelů identity:

V tomto příkladu předpokládáme:

1. Každý systém, na který se to týká, je nastavený tak, aby pro jednotné přihlašování používal vašeho zprostředkovatele identity (například Microsoft Entra ID).
2. Skupiny zprostředkovatelů identit (například skupiny Entra) v systémech použijete ke správě členství podle rolí, abyste snížili složitost a zachovali centralizované auditování.

Na základní úrovni funguje tento model takto:

1. Centrální uzamčené úložiště Git obsahuje sadu souborů (obvykle YAML), které představují jednotlivé abstraktní týmy, související členství uživatelů a role uživatelů. Vlastníci/schvalovatelé týmových změn mohou být také uloženi na stejném místě (například prostřednictvím CODEOWNERS). Odkaz na uživatele v těchto souborech je zprostředkovatel identity, ale toto úložiště funguje jako zdroj pravdy pro tyto týmy (ale ne pro uživatele).
2. Stejně jako v jiných případech se všechny aktualizace těchto souborů provádějí prostřednictvím žádostí o přijetí změn. Tato akce spojuje konverzace a související účastníky žádosti o potvrzení gitu z důvodu auditovatelnosti.
3. Potenciální zákazníci a jednotliví uživatelé můžou žádosti o přijetí změn vytvářet a přidávat nebo odebírat lidi. Vedoucí vývoje a další role můžou vytvářet nové týmy pomocí žádostí o přijetí změn s novým týmovým souborem ze šablony.
4. Pokaždé, když se žádost o přijetí změn sloučí do main, systém CI/CD svázaný s úložištěm pak podle potřeby aktualizuje systém zprostředkovatele identity a všechny podřízené systémy.

Konkrétně systém CI/CD:

5. Používá příslušné rozhraní API systému zprostředkovatele identity k vytvoření nebo aktualizaci skupiny zprostředkovatelů identit pro každou roli přesně s osobami v souboru (nic víc, ani méně).
6. Používá rozhraní API pro každý podřízený systém k provázání konceptu seskupení systémů s identifikací skupin zprostředkovatelů pro každou roli (příklad: GitHub a Azure DevOps). To může mít za následek vztah 1:N mezi vaším týmem a podřízeným systémem, který bude představovat roli.
7. Volitelně používá rozhraní API pro každý podřízený systém k implementaci logiky oprávnění vázané na mechanismus seskupování systému.
8. Používá rozhraní API k aktualizaci uzamčeného úložiště dat o výsledky (včetně přidružení ID podřízených systémových týmů), které je pak možné využít pro jakýkoli interně sestavený systém. V případě potřeby můžete také uložit přidružení pro různé systémové reprezentace ID uživatelů pro stejného uživatele nebo účet zprostředkovatele identity.

Mějte na paměti, že pokud už vaše organizace používá něco jako Entra Entitlement Management, možná budete moct správu členství ve skupinách vynechat.

Vaše potřeby a zásady můžou změnit specifika, ale obecný vzor je možné přizpůsobit libovolnému počtu variant. Všechny tajné kódy potřebné k integraci s podřízenými systémy se uchovávají buď v systému CI/CD (například v GitHub ActionsAzure Pipelines), nebo v azure Key Vault.

Použití ručně nebo externě aktivovaných parametrizovaných pracovních postupů

Některé problémy související se samoobslužnou službou, které identifikujete, nemusí být pro používání souborů v Gitu vhodné. Nebo můžete mít uživatelské rozhraní, které chcete použít k řízení samoobslužného prostředí.

Většina systémů ci, včetně GitHub Actions a Azure Pipelines, naštěstí dokáže nastavit pracovní postup se vstupy, které pak můžete aktivovat ručně prostřednictvím jejich uživatelských rozhraní nebo rozhraní příkazového rozhraní. Vzhledem k tomu, že vývojáři a související provozní role jsou pravděpodobně již obeznámeni s těmito uživatelskými prostředími, můžou ruční triggery rozšířit vše jako vzor kódu a umožnit automatizaci pro aktivity (nebo úlohy), které buď nemají přirozenou reprezentaci souborů, nebo by měly být plně automatizované bez nutnosti procesu žádosti o přijetí změn.

Ve skutečnosti vám systém CI může umožnit, abyste tyto pracovní postupy nebo kanály aktivovala z vlastních uživatelských prostředí prostřednictvím rozhraní API. Pro GitHub Actions je klíčem k tomu, aby to fungovalo, rozhraní REST API akcí, které aktivuje událost odeslání pracovního postupu, která aktivuje spuštění pracovního postupu. Triggery Azure DevOps jsou podobné a pro spuštění můžete použít také rozhraní API kanálu Azure DevOps. Stejné funkce pravděpodobně uvidíte i v jiných produktech. Bez ohledu na to, jestli se aktivuje ručně nebo prostřednictvím rozhraní API, může každý pracovní postup podporovat sadu vstupů přidáním konfigurace workflow_dispatch do souboru YAML pracovního postupu. Takto například pracují s GitHub Actions sady nástrojů portálu, jako jsou Backstage.io.

Systém pracovních postupů nebo úloh systému CI/CD nepochybně sleduje aktivity, hlásí stav a obsahuje podrobné protokoly, které můžou vývojáři i provozní týmy použít ke zjištění, co se nepovedlo. Tímto způsobem má některé stejné výhody zabezpečení, auditovatelnosti a viditelnosti jako vše jako vzor kódu. Mějte ale na paměti, že všechny akce prováděné těmito pracovními postupy nebo kanály vypadají v podřízených systémech jako systémová identita (například instanční objekt nebo spravovaná identita v Microsoft Entra ID).

Budete mít přehled o tom, kdo ve vašem systému CI/CD iniciuje požadavky, ale měli byste posoudit, jestli je to dostatek informací, a zajistit, aby nastavení uchovávání CI/CD splňovalo vaše požadavky na auditování v případech, kdy jsou tyto informace kritické.

V jiných případech můžou mít nástroje, se kterými se integrujete, své vlastní mechanismy sledování, na které se můžete spolehnout. Například tyto nástroje CI/CD mají téměř vždy k dispozici několik mechanismů oznámení, jako je použití kanálu Microsoft Teams nebo Slack , což vám umožní udržet si všechny, kteří odesílali žádost o aktualizace stavu, a kanál poskytuje neformální záznam o tom, co se stalo. Tyto moduly pracovních postupů jsou často již navrženy tak, aby se integrovali s provozními nástroji, aby se dále rozšiřily užitečnost těchto vzorů.

Stručně řečeno, můžete implementovat určitou automatizaci pomocí souborů uložených v úložišti správy zdrojového kódu díky flexibilitě nástrojů CI/CD a jejich předefinovaných uživatelských prostředí.

Pokud chcete zjistit, jak můžou interní vývojářské platformy tento přístup využít jako výchozí bod, aniž by to časem ohrozilo sofistikovanější funkce, přečtěte si téma Návrh samoobslužných základů pro vývojáře.

Automatizace nastavení prostředí pro kódování pro vývojáře

Dalším běžným problémem, se kterým vám můžou pomoct technické systémy, je spouštění a normalizace prostředí pro kódování pro vývojáře. Tady jsou některé běžné problémy, o nichž se můžete setkat v této oblasti:

• V některých případech může trvat týdny, než se vývojář dostane k první žádosti o přijetí změn. Jedná se o problematickou oblast, kdy poměrně často převádíte vývojáře mezi týmy funkcí a projekty (například v organizacích s maticí), potřebujete navýšit dodavatele nebo jste v týmu, který je ve fázi náboru.
• Nekonzistence mezi vývojáři a vašimi systémy CI může vést k častým problémům "funguje na mém počítači" i pro ostřílené členy týmu.
• Experimentování a upgrade architektur, doby spuštění a dalšího softwaru mohou také narušit stávající vývojářská prostředí a způsobit ztrátu času při hledání toho, co přesně se nepovedlo.
• U potenciálních vývojářů můžou revize kódu zpomalit vývoj, protože můžou vyžadovat změnu konfigurace pro jejich testování a vrácení zpět po dokončení kontroly.
• Členové týmu a operátoři také musí trávit čas zužováním souvisejících rolí nad rámec vývoje (operátoři, kontrola kvality, podnikání, sponzoři), aby mohli pomáhat s testováním, zobrazením pokroku, trénováním obchodních rolí a osvětou práce, kterou tým dělá.

Část zpevněných cest

Pokud chcete tyto problémy vyřešit, zamyslete se nad nastavením konkrétních nástrojů v rámci dobře definovaných zpevněných cest. Může vám pomoct nastavení počítače pro vývojáře skriptování a stejné skripty můžete znovu použít v prostředí CI. Zvažte ale podporu kontejnerizovaných nebo virtualizovaných vývojových prostředí kvůli výhodám, které mohou poskytnout. Tato programovací prostředí je možné nastavit předem podle specifikací vaší organizace nebo projektu.

Nahrazení pracovní stanice a cílení na Windows

Pokud cílíte na Windows nebo chcete provést úplnou virtualizaci pracovních stanic (klientské nástroje a nastavení hostitelského operačního systému kromě nastavení specifických pro projekt), virtuální počítače obvykle poskytují nejlepší funkce. Tato prostředí můžou být užitečná pro cokoli od vývoje klientů windows až po službu Windows nebo správu a údržbu webových aplikací .NET Full Framework.

Přístup	Příklady
Použití virtuálních počítačů hostovaných v cloudu	Microsoft Dev Box je možnost úplné virtualizace pracovní stanice Windows s integrovanou integrací softwaru pro správu stolních počítačů.
Použití místních virtuálních počítačů	Hashicorp Vagrant je dobrá volba a můžete použít HashiCorp Packer k sestavení imagí virtuálních počítačů pro něj i Pro Dev Box.

Virtualizace pracovního prostoru a cílení na Linux

Pokud cílíte na Linux, zvažte možnost virtualizace pracovního prostoru. Tyto možnosti se zaměřují méně na nahrazení plochy vývojáře a více na pracovní prostory specifické pro projekt nebo aplikaci.

Přístup	Příklady
Použití kontejnerů hostovaných v cloudu	GitHub Codespaces je cloudové prostředí pro Dev Containers, které podporuje integraci s VS Code, IntelliJ od JetBrains a terminálové nástroje. Pokud tato nebo podobná služba nevyhovuje vašim potřebám, můžete na vzdálených virtuálních počítačích s Linuxem použít podporu SSH nebo vzdálených tunelů ve VS Code se službou Dev Containers. Možnost založená na tunelu, která funguje nejen s klientem, ale i s webovými vscode.dev.
Použití místních kontejnerů	Pokud dáváte přednost místní službě Dev Containers nebo k možnosti hostované v cloudu, mají dev containers solidní podporu v nástroji VS Code, podporu v IntelliJ a dalších nástrojích a službách.
Použití virtuálních počítačů hostovaných v cloudu	Pokud zjistíte, že kontejnery jsou příliš omezující, podpora SSH v nástrojích, jako jsou VS Code nebo JetBrains, jako je IntelliJ, vám umožní připojit se přímo k virtuálním počítačům s Linuxem, které spravujete sami. VS Code má také možnost založená na tunelu .
Použití Subsystém Windows pro Linux	Pokud vaši vývojáři používají výhradně Windows, je Subsystém Windows pro Linux (WSL) skvělým způsobem, jak můžou místně cílit na Linux. Distribuci WSL můžete exportovat pro svůj tým a sdílet ji se vším, co je nastavené. Cloudové služby pracovních stanic, jako je Microsoft Dev Box, můžou také využít WSL a zaměřit se na vývoj pro Linux.

Vytváření šablon aplikací, které jsou vhodné pro spuštění, které obsahují správnou konfiguraci

Na vzoru kódu je skvělé, že může vývojáře udržet na zpevněných cestách, které jste si vytvořili od začátku. Pokud je to pro vaši organizaci výzva, šablony aplikací se můžou rychle stát důležitým způsobem, jak opakovaně používat stavební bloky k zajištění konzistence, podpoře standardizace a kodifikování osvědčených postupů vaší organizace.

Pro začátek můžete použít něco tak jednoduchého, jako je úložiště šablon GitHubu, ale pokud se vaše organizace řídí vzorem monorepo , může to být méně efektivní. Můžete také vytvořit šablony, které vám pomůžou nastavit něco, co nesouvisí přímo se stromem zdroje aplikace. Místo toho můžete použít modul šablon, jako je cookiecutter, Yeoman, nebo něco jako Azure Developer CLI (azd), který kromě šablon a zjednodušeného nastavení CI/CD poskytuje také pohodlnou sadu vývojářských příkazů. Vzhledem k tomu, že Azure Developer CLI lze použít k řízení nastavení prostředí ve všech scénářích, integruje se s prostředími pro nasazení Azure a poskytuje lepší zabezpečení, integrované IaC, sledování prostředí, oddělení oblastí zájmu a zjednodušené nastavení CD.

Jakmile budete mít sadu šablon, můžou potenciální vývojáři použít tyto nástroje příkazového řádku nebo jiné integrované uživatelské prostředí k vygenerování obsahu pro své aplikace. Vzhledem k tomu, že vývojáři nemusí mít oprávnění k vytváření úložišť nebo jiného obsahu z vašich šablon, je to také další příležitost, jak použít ručně aktivované parametrizované pracovní postupy nebo kanály. Můžete nastavit vstupy, aby váš systém CI/CD vytvořil za ně cokoli od úložiště až po infrastrukturu.

Zůstat v pořádku a správně

Pokud ale chcete usnadnit škálování, měly by tyto šablony aplikací odkazovat tam, kde je to možné, na centralizované stavební bloky (například šablony IaC nebo dokonce na pracovní postupy nebo kanály CI/CD). Ve skutečnosti můžete zjistit, že zacházejte s těmito centralizovanými stavebními bloky jako s vlastní formou šablon se správným zahájením, je účinná strategie řešení některých problémů, které jste identifikovali.

Každou z těchto jednotlivých šablon je možné použít nejen u nových aplikací, ale také u těch stávajících, které chcete aktualizovat v rámci správné kampaně za účelem zavedení aktualizovaných nebo vylepšených pokynů. A co je ještě lepší, tato centralizace pomáhá zajistit, aby nové i stávající aplikace zůstaly v pořádku, což vám umožní vyvíjet nebo rozšiřovat osvědčené postupy v průběhu času.

Obsah šablony

Při vytváření šablon doporučujeme zvážit následující oblasti.

Oblasti	Podrobnosti
Dostatečný ukázkový zdrojový kód pro řízení vzorů aplikací, sad SDK a použití nástrojů	Zahrňte kód a konfiguraci, které nasměrují vývojáře k doporučeným jazykům, modelům a službám aplikací, rozhraním API, sadm SDK a vzorům architektury. Nezapomeňte zahrnout kód pro distribuované trasování, protokolování a pozorovatelnost pomocí nástrojů podle vašeho výběru.
Skripty sestavení a nasazení	Poskytněte vývojářům běžný způsob, jak aktivovat sestavení a místní nasazení nebo nasazení sandboxu. Zahrňte konfiguraci ladění v integrovaném vývojovém prostředí (IDE) nebo editoru pro zvolené nástroje, abyste je mohli používat. Jedná se o důležitý způsob, jak se vyhnout bolestem hlavy při údržbě a zabránit nesynchronizování CI/CD. Pokud je modul šablon shodný s názorem jako Azure Developer CLI, můžou už existovat příkazy, které můžete použít.
Konfigurace pro CI/CD	Poskytovat pracovní postupy a kanály pro sestavování a nasazování aplikací na základě vašich doporučení. Využijte centralizované, opakovaně použitelné nebo šablonované pracovní postupy nebo kanály a udržujte je v aktuálním stavu. Tyto opakovaně použitelné pracovní postupy nebo kanály můžou ve skutečnosti spouštět vlastní šablony. Nezapomeňte zvážit možnost ruční aktivace těchto pracovních postupů.
Infrastruktura jako prostředky kódu	Uveďte doporučené konfigurace IaC, včetně odkazů na centrálně spravované moduly nebo položky katalogu , abyste zajistili, že se veškeré nastavení infrastruktury bude řídit osvědčenými postupy z úvodních postupů. Tyto reference také můžou týmům pomoct udržet si správný čas. V kombinaci s pracovními postupy nebo kanály můžete také zahrnout IaC nebo EaC a zřizovat prakticky cokoli.
Zabezpečení a zásady jako prostředky kódu	Přesun DevSecOps také přesunul konfiguraci zabezpečení do kódu, což je skvělé pro šablony. Některé zásady jako artefakty kódu je také možné použít na úrovni aplikace. Zahrnout jako vše od souborů jako CODEOWNERS až po konfiguraci skenování, jako je dependabot.yaml v GitHub Advanced Security. Poskytněte naplánované pracovní postupy nebo spuštění kanálu pro kontroly, jako je Defender for Cloud , a testovací běhy prostředí. To je obzvláště důležité pro zabezpečení dodavatelského řetězce a nezapomeňte kromě balíčků aplikací a kódu zohlednit i image kontejnerů . Tyto kroky pomáhají vývojovými týmy zůstat v pořádku.
Pozorovatelnost, monitorování a protokolování	Součástí povolení samoobslužné služby je poskytování snadného přehledu o aplikacích po nasazení. Kromě infrastruktury modulu runtime nezapomeňte zahrnout nastavení pro pozorovatelnost a monitorování. Ve většině případů nastavení existuje aspekt IaC (například nasazení agenta nebo instrumentace), zatímco v jiných se může jednat o jiný typ artefaktu kódu konfigurace jako (například monitorování řídicích panelů pro Aplikace Azure Insights). Nakonec nezapomeňte zahrnout vzorový kód pro distribuované trasování, protokolování a pozorovatelnost pomocí nástrojů podle vašeho výběru.
Nastavení prostředí pro kódování	Zahrnout konfigurační soubory pro kódování linterů, formátovacích nástrojů, editorů a prostředí IDE. Zahrňte instalační skripty spolu se soubory virtualizace pracovního prostoru nebo pracovní stanice, jako jsou soubory devcontainer.json, devbox.yaml, soubory Docker Compose zaměřené na vývojáře, soubory Docker Compose nebo soubory Vagrantfiles.
Test konfigurace	Poskytněte konfigurační soubory pro testování jednotek i podrobnější testování pomocí upřednostňovaných služeb, jako je Microsoft Playwright Testing pro uživatelské rozhraní nebo azure load testing.
Nastavení nástroje pro spolupráci	Pokud váš systém správy problémů a správy zdrojového kódu podporuje jako kód šablony úloh, problémů nebo žádostí o přijetí změn, zahrňte je také. V případech, kdy je potřeba více nastavení, můžete volitelně zadat pracovní postup nebo kanál, který aktualizuje vaše systémy pomocí dostupného rozhraní příkazového řádku nebo rozhraní API. To vám také umožní nastavit další nástroje pro spolupráci, jako je Microsoft Teams nebo Slack.

Zpřesnění aplikační platformy