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

Článek
07/25/2024

Zlepšení samoobslužné služby pro vývojáře by mělo být jedním z prvních problémů, které řešíte na své cestě přípravy platformy.

Jedním z nejjednodušších způsobů, jak začít povolovat automatizované samoobslužné prostředí, je opětovné použití stávajících technických systémů. Tyto systémy jsou nejen pro vás a vaše interní zákazníky známé, ale můžou povolit širokou škálu scénářů automatizace, i když počáteční uživatelské prostředí není hezké.

Tento článek obsahuje tipy pro použití technických systémů pro řešení širší škály samoobslužných scénářů a podrobnosti o tom, jak zapouzdření osvědčených postupů 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. Interní vývojářské platformy se vytvářejí z hlavních tenantů DevOps a DevSecOps, aby se snížila kognitivní zátěž pro všechny zúčastněné uživatele.

DevOps kombinuje vývoj a operace, které spojují lidi, procesy a technologie v oblasti plánování aplikací, vývoje, doručování a provozu. Cílem je zlepšit spolupráci napříč historicky vysílaný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 vrství do této smyčky s průběžnými postupy zabezpečení v průběhu procesu vývoje aplikací.

Obrázek životního cyklu DevOps s plánem, doručováním, vývojem a provozem

Následující části se zaměřují na vylepšení přímo přiřazovaná přesunu přípravy platformy: zpevněné cesty, automatizované zřizování infrastruktury (kromě nasazení aplikací), nastavení prostředí kódování spolu se samoobslužným zřizováním a konfigurací 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, je jedním z prvních rozhodnutí, jestli je chcete konsolidovat jako součást počátečního úsilí o přípravu platformy nebo pokud budete podporovat souhvězdí různých nástrojů od počátku. Definování sady zpevněných cest v rámci tohoto souhvězdí nástrojů je nejúčinnější a poskytuje zvýšenou úroveň flexibility.

Když se začnete přesouvat k produktovému myšlení, představte si technické systémy v rámci těchto zpevněných cest 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 můžou odchýlit, ale očekává se, že budou spravovat, udržovat a platit za své nástroje samostatně, 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 v průběhu času liší od možného zahrnutí do zpevněné cesty. Jako vedoucí přípravy jedné platformy je uvedeno:

Pořád si můžete udělat vlastní věc, ale udělat to ve směru, ve kterém budeme... můžete změnit, co chcete, ale to se stane vaší zodpovědností. Vlastníte změny – vlastníte ostré nože. - Mark, vedoucí inženýrských platforem, velká evropská nadnárodní maloobchodní společnost

Vzhledem k tomu, že klíčovým cílem pro přípravu platforem je přechod na produktovou mysl, kde poskytujete hodnotu interním zákazníkům, tento přístup souhvězdí obvykle funguje lépe než mandát shora dolů. Při vytváření a upřesňování zpevněných cest umožňuje týmům poskytovat vstup a řešit skutečné jedinečné požadavky pro danou aplikaci, aniž by to mělo vliv na ostatní v organizaci. To vede k sadě plně zpevněných, zlatých cest, zatímco ostatní jsou jen částečně zpevněné. V případech, kdy neexistují žádné jedinečné požadavky, týmy pro vývoj navíc přirozeně způsobí, že se budou chtít v průběhu času přesunout na podporovanou cestu.

Pokud dáváte přednost strategii konsolidace, migrace stávajících aplikací může být více práce, 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 dává první zpevněnou cestu, zatímco vše, co existuje, je ze své podstaty neprůmyslné. Vývojové týmy na nepovedené cestě pak budou zvažovat přesun, jakmile nová zpevněná cesta zobrazí její hodnotu pro organizaci. V tomto okamžiku můžete spustit správnou kampaň, abyste všem uživatelům v požadovaném stavu získali obousměrnou komunikaci, protože vývojové týmy tuto výhodu považují za výhodu, a ne jako daň. Během kampaně se technické týmy platformy můžou soustředit na pomoc týmům s migrací, zatímco vývojové týmy poskytují zpětnou vazbu o tom, jak vylepšit zpevněné cesty.

Bez ohledu na to, vyhněte se používání zpevněných cest. Nejúčinnějším způsobem, jak zavést zpevněné cesty, je zdůraznit, jaké týmy se z nich dostanou, a ne prostřednictvím vynuceného přijetí. Vzhledem k tomu, že se vaše interní vývojářská platforma zaměřuje na to, aby tyto přesně stejné týmy byly šťastné, rozpočet a tlak na čas na hodnoty jednotlivých vedoucích pracovníků se postará o zbytek. Získejte správné kampaně a pak poskytněte možnost obousměrných konverzací na nejlepší cestě pro ty, kteří mají neprůměrnou cestu k přepnutí.

Použití nástrojů pro automatizaci vývojářů ke zlepšení samoobslužných služeb pro zpevněné cesty

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

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ůžou pomoct vyřešit kontinuální integrace (CI) a průběžné doručování (CD). Produkty, jako jsou GitHub Actions, Azure DevOps , Jenkins, spolu s řešeními GitOps založenými na vyžádání, jako je Flux nebo Argo CD, existují v tomto prostoru. Tato témata můžete začít používat v centru prostředků Microsoft DevOps.

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

Podívejte se například na tyto ilustrace, které ukazují dva přístupy, které používají GitHub Actions k aktualizaci infrastruktury a nasazení do služby Azure Kubernetes Service: jedno s využitím nasazení založených na nabízených oznámeních a jedno nasazení založené na vyžádání obsahu (GitOps).

Kterou zvolíte, je řízena vaší stávající sadou dovedností IaC a podrobnostmi o vaší cílové aplikační platformě. Přístup GitOps je novější a je mezi organizacemi, které používají Kubernetes jako základ pro své aplikace, zatímco model založený na vyžádá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í používá kombinaci těchto dvou. Bez ohledu na to, že se v postupech IaC dobře seznámíte, pomůže vám naučit se vzory, které platí pro další scénáře automatizace.

Centralizace IaC v katalogu nebo registru pro š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, modulech Bicep, receptech radiusu nebo chartech Helm uložených v nativním cloudovém registru artefaktů OCI, jako je Azure Container Registry (ACR), DockerHub nebo katalog v prostředích nasazení Azure (ADE). V případě GitOps a Kubernetes může rozhraní API clusteru (a implementace, jako je CAPZ), umožnit správu clusterů ú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 jsou prostředky podpory Crossplane napříč několika cloudy. Díky těmto grafům můžete použít 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 vám dává lepší kontrolu nad tím, kdo může provádět aktualizace, protože už nejsou uložené s kódem aplikace. Při aktualizaci kódu, kdy odborníci, provoz nebo technici platformy dělají potřebné změny, není riziko náhodného přerušení způsobené neúmyslnou změnou. Vývojáři také těží z těchto stavebních bloků, protože nemusí vytvářet kompletní šablony IaC sami a automaticky těžit z kódovaných osvědčených postupů.

Který formát IaC zvolíte, závisí na vaší stávající sadě dovedností, na úrovni kontroly, kterou potřebujete, a na modelu aplikace, který používáte. Například Azure Container Apps (ACA) a nedávný experimentální projekt inkutace OSS radius jsou názornější než přímé použití Kubernetes, ale také zefektivnit vývojářské prostředí. 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, že odkazování na centralizované a spravované IaC místo kompletních definic ve zdrojovém stromu má významné výhody.

Zachování všech potřebných identit zřizování nebo tajných kódů způsobem, který vývojáři nemají přímý přístup k jejich vrstvám v základních stavebních blocích zásad správného řízení. Podívejte se například na tento obrázek o oddělení rolí, které můžete dosáhnout pomocí prostředí nasazení Azure (ADE).

Zde vývojáři platformy a další specialisté vyvíjejí IaC a další šablony a umístí 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 kanál CI/CD pak můžou pomocí Azure CLI nebo Azure Developer CLI zřizovat předkonfigurovanou a řízenou infrastrukturu, aniž by k tomu museli mít přístup k podkladovému předplatnému nebo identitám potřebným k tomu. Ať už používáte něco jako ADE nebo ne, váš systém průběžného doručování vám může pomoct bezpečně a bezpečně aktualizovat infrastrukturu oddělením tajného kódu a zdroje obsahu IaC od umístění, ke které vývojáři nemají přístup nebo je sami upravovat.

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

Koncepty CI a CD jsou spojené s vývojem aplikací, ale mnoho věcí, které vaši interní zákazníci chtějí zřídit, přímo neváže na konkrétní aplikaci. Může se jednat o sdílenou infrastrukturu, vytvoření úložiště, nástroje pro zřizování a další.

Pokud chcete zjistit, kde to může pomoct, zamyslete se nad tím, kde aktuálně máte ruční nebo servisní procesy. Pro každou 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 vyžaduje, aby se dosáhlo významné práce?
Jsou tyto procesy ruční z důvodu požadovaného schvalovacího kroku nebo jednoduše nedostatečné automatizace?
Jsou schvalovatelé obeznámeni se 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 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ší procesy?

Identifikujte časté, vysoké úsilí nebo procesy náchylné k chybám jako potenciální cíle, které se mají automatizovat jako první.

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

Jednou z pěkných věcí o Gitu kromě jeho všudypřítomnosti je, že má být bezpečným, 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í před sloučením do hlavní větve projít. V kombinaci s flexibilními moduly úloh, jako jsou moduly, které se nacházejí v systémech CI/CD, máte zabezpečenou architekturu automatizace.

Myšlenka za vším, jak je kód, spočívá v tom, že můžete téměř cokoli převést na soubor v zabezpečeném úložišti Git. Obsah pak můžou číst různé nástroje nebo agenti připojené k úložišti. Zacházení se vším jako 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

IaC získala popularitu pro automatizaci doručování aplikací, ale vzor se rozšiřuje na jakoukoli infrastrukturu, nástroje nebo služby, které byste mohli chtít zřídit a nakonfigurovat – nejen ty, které jsou svázané s konkrétní aplikací. Například sdílené K8s s clustery s nainstalovaným fluxem, zřizováním něčeho, jako je DataDog , který používá více týmů a aplikací, nebo dokonce nastavení oblíbených nástrojů 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). Provozní tým nebo jiná sada správců vlastní úložiště a vývojáři (nebo systémy) můžou odesílat žádosti o přijetí změn. Po sloučení těchto žádostí o přijetí změn do hlavní větve těmito správci můžou ke zpracování změn začít stejné nástroje CI/CD používané při vývoji aplikací. Představte si tento obrázek, který používá GitHub Actions a identity IaC a nasazení v prostředích nasazení Azure:

Pokud už pro nasazení aplikací používáte přístup GitOps , můžete tyto nástroje znovu použít. Kombinace nástrojů, jako je Flux a Operátor služby Azure, umožňuje rozbalit mimo Kubernetes:

V obou případech máte plně spravovaný, reprodukovatelný a auditovatelný zdroj informací – i když se vytváří pro aplikaci. Stejně jako u vývoje aplikací se všechny tajné kódy nebo spravované identity, které potřebujete, ukládají v modulu kanálu nebo pracovního postupu nebo v nativních funkcích služby zřizování.

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

Sledování zřízené infrastruktury

Když začnete tento přístup škálovat, zamyslete se nad tím, jak chcete sledovat zřízenou infrastrukturu. Úložiště Git je zdrojem pravdivých informací o konfiguraci, ale neřekne vám konkrétní identifikátory URI a informace o stavu, které jste vytvořili. Když ale budete sledovat vše jako přístup ke kódu, získáte zdroj informací, který vám umožní syntetizovat inventář zřízené infrastruktury. Váš zřizovací objekt může být také dobrým zdrojem těchto informací, ke kterým můžete využít přístup. Prostředí nasazení Azure například zahrnuje možnosti sledování prostředí, na které mají vývojáři přehled.

Další informace o sledování různých zdrojů dat najdete v tématu Návrh samoobslužného základu pro vývojáře.

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

I když je infrastruktura zřizování užitečná, ujistěte se, že jsou tato prostředí zabezpečená a obecně se řídí zásadami vaší organizace, je stejně důležitá. To vedlo k nárůstu konceptu "zásady jako kódu". Tady se konfigurační soubory v úložišti správy zdrojového kódu dají použít k provedení věcí, jako je kontrola zabezpečení jednotky nebo použití zásad infrastruktury.

Mnoho různých produktů a opensourcových projektů tento přístup podporuje, včetně Azure Policy, open policy agenta, GitHub Advanced Security a GitHub CODEOWNERS. Při výběru infrastruktury aplikace, služeb nebo nástrojů nezapomeňte vyhodnotit, jak dobře tyto vzory podporují. Další informace o upř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. Může podporovat 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 prostředím uživatelů samoobslužných služeb pro různé procesy – zejména když začínáte. Procesy přirozeně získávají výhody zabezpečení, auditovatelnosti a vrácení zpět, které git sám poskytuje, a systémy, které se týkají, se můžou v průběhu času měnit i bez dopadu na uživatelské prostředí.

Teams jako kód

Jedním z příkladů použití všeho jako kódu pro vaše vlastní scénáře je tým jako vzor kódu. Organizace tento model aplikují na standardizaci členství v týmu a v některých případech nároky na nástroje pro vývojáře nebo služby napříč širokou škálou systémů. Tento model eliminuje ruční procesy onboardingu a zrušení zprovoznění služeb, které jsou řízené potřebou vývojářů a operátorů systémů pro přístup k vlastním konceptům seskupení, uživatelů a přístupu. Ruční procesy oddělení služeb představují potenciální bezpečnostní riziko, protože je možné převést přístup. Při použití týmů jako vzoru kódu může kombinace gitu a žádostí o přijetí změn povolit samoobslužnou službu ze zdroje dat, který je možné auditovat.

Příklad vyspělého, rozsáhlého variace tohoto vzoru, se podívejte na blogový příspěvek GitHubu o tom, jak spravují nároky. GitHub má také opensourcovou implementaci důmyslných nároků, kterou si 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 zúženější scénáře vývojového týmu. Tyto vývojové týmy nemusí být vůbec reprezentovány v organizačním diagramu zaměstnanců a zahrnují proprietární nástroje nebo služby, které mohou komplikovat onboarding nebo offboarding členů týmu.

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

V tomto příkladu:

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

Na vysoké úrovni funguje tento model:

Centrální uzamčené úložiště Git obsahuje sadu souborů (obvykle YAML), které představují každý abstraktní tým, související členství uživatelů a role uživatelů. Vlastníci nebo schvalovatelé pro změny týmu 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ředkovatelem identity, ale toto úložiště funguje jako zdroj pravdy pro tyto týmy (ale ne uživatele).
Všechny aktualizace těchto souborů se provádějí prostřednictvím žádostí o přijetí změn. Tím se prováže konverzace a související účastníci na žádosti o potvrzení gitu pro auditovatelnost.
Potenciální zákazníci a jednotliví uživatelé můžou vytvářet žádosti o přijetí změn, aby mohli přidávat nebo odebírat lidi, a vývojáři a další role můžou vytvářet nové týmy pomocí žádostí o přijetí změn, které mají nový týmový soubor ze šablony.
Pokaždé, když se žádost o přijetí změn sloučí do hlavního systému, 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:

Použije příslušné rozhraní API systému zprostředkovatele identity k vytvoření nebo aktualizaci skupiny zprostředkovatelů identit na roli s přesně jednotlivci v souboru (ne více, ne méně).
Používá rozhraní API pro každý podřízený systém ke svázání konceptu seskupení těchto systémů s identifikací skupin poskytovatelů pro každou roli (například GitHub a Azure DevOps). Výsledkem může být vztah 1:N mezi vaším týmem a podřízeným systémem, který představuje roli.
(Volitelně) Používá rozhraní API pro každý podřízený systém k implementaci logiky oprávnění svázané s mechanismem seskupení systému.
Pomocí rozhraní API aktualizuje uzamčené úložiště dat s výsledky (včetně přidružení ID podřízeného systémového týmu), které je pak možné využívat pro kterýkoli z vašich interně sestavených 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 účtu zprostředkovatele identity.

Pokud už vaše organizace používá něco jako Entra Entitlement Management, můžete z tohoto vzoru vynechat správu členství ve skupinách.

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 se všemi podřízenými systémy se udržují buď v systému CI/CD (například v GitHub Actions, Azure Pipelines), nebo v něčem, jako je Azure Key Vault.

Použití ručních 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 příznivé. 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, má naštěstí možnost nastavit pracovní postup se vstupy, které pak můžete ručně aktivovat prostřednictvím jejich uživatelských rozhraní nebo rozhraní CLI. Vzhledem k tomu, že vývojáři a související provozní role už jsou s těmito uživatelskými prostředími pravděpodobně obeznámeni, můžou ruční triggery rozšířit všechno jako vzor kódu, aby bylo možné automatizovat aktivity (nebo úlohy), které nemají přirozenou reprezentaci souborů, nebo by měly být plně automatizované, aniž by vyžadovaly proces žádosti o přijetí změn.

Váš systém CI vám může umožnit vyjádřit výslovný souhlas s aktivací těchto pracovních postupů nebo kanálů z vlastních uživatelských prostředí prostřednictvím rozhraní API. V případě GitHub Actions je klíčem k provedení této práce rozhraní REST API Akcí, které aktivuje událost odeslání pracovního postupu pro aktivaci spuštění pracovního postupu. Triggery Azure DevOps jsou podobné a pro spuštění můžete také použít rozhraní API kanálu Azure DevOps. Pravděpodobně uvidíte stejné funkce v jiných produktech. Bez ohledu na to, jestli se aktivovalo 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. Toto je například způsob, jakým portálové sady nástrojů, jako je Backstage.io interakce s GitHub Actions.

Pracovní postup nebo systém úloh CI/CD nepochybně sleduje aktivity, hlásí stav zpět a obsahuje podrobné protokoly, které můžou vývojáři i provozní týmy použít k zobrazení toho, 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í jako systémová identita (například instanční objekt nebo spravovaná identita v Microsoft Entra ID) do podřízených systémů.

Budete mít přehled o tom, kdo inicializuje požadavky ve vašem systému CI/CD, ale měli byste posoudit, jestli je to dostatek informací, a ujistit se, že nastavení uchovávání CI/CD vyhovuje vašim požadavkům na auditování v případech, kdy jsou tyto informace důležité.

V jiných případech můžou mít nástroje, se kterými se integrujete, 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 , které vám umožní ponechat 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 navržené tak, aby se integrují s provozními nástroji, aby se dále rozšířily užitečnost těchto vzorů.

Stručně řečeno, můžete implementovat některé automatizace 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 používat jako výchozí bod, aniž by došlo k ohrožení sofistikovanějších funkcí v průběhu času, přečtěte si téma Návrh samoobslužné služby pro vývojáře.

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

Dalším běžným problémem v technických systémech je spouštění a normalizace prostředí pro vývojáře. Tady jsou některé běžné problémy, o nichž můžete slyšet v této oblasti:

V některých případech může vývojářům trvat týdny, než se dostane k první žádosti o přijetí změn. Jedná se o problematickou oblast, když přenášíte vývojáře mezi posádkami funkcí a projekty poměrně často (například v maticových organizacích), potřebujete zvýšit dodavatele nebo jsou 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 s "funguje na mém počítači", a to i pro členy týmu s ochucenými členy týmu.
Experimentování a upgrade architektur, časů spuštění a dalšího softwaru můžou také narušit stávající vývojářská prostředí a vést ke ztrátě času při pokusu zjistit, co se nepovedlo.
U potenciálních zákazníků vývojářů můžou kontroly kódu zpomalit vývoj, protože po dokončení kontroly můžou vyžadovat změnu konfigurace, která je otestuje a vrátí zpět.
Členové týmu a operátoři také musí trávit čas tím, že zvýrazní související role nad rámec vývoje (operátoři, kontrola kvality, podnikání, sponzory), aby pomohli testovat, sledovat průběh, trénovat obchodní role a normalizovat práci, 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ů a nástrojů jako součást dobře definovaných cest. Skriptování vývojářského počítače může pomoct a stejné skripty můžete znovu použít ve svém prostředí CI. Zvažte ale podporu kontejnerizovaných nebo virtualizovaných vývojových prostředí z důvodu výhod, které můžou poskytnout. Tato programovací prostředí je možné nastavit předem podle specifikací vaší organizace nebo projektu.

Nahrazení pracovních stanic a cílení na Windows

Pokud cílíte na Windows nebo chcete provádět plnou virtualizaci pracovních stanic (kromě nastavení specifických pro projekt a hostování operačního systému), 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ů pro Windows až po službu Windows nebo správu a údržbu webových aplikací .NET s plnou architekturou.

Přístup	Příklady
Použití virtuálních počítačů hostovaných v cloudu	Microsoft Dev Box je úplná možnost virtualizace pracovních stanic s Windows s integrovanou integrací do softwaru pro správu stolních počítačů.
Použití místních virtuálních počítačů	Hashicorp Vagrant je dobrá možnost 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 pro vývojáře a další informace o pracovních prostorech specifických 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, JetBrainsem IntelliJ a terminálovými nástroji. 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ů VS Code. 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 místo toho dáváte přednost místní možnosti Dev Containers nebo kromě cloudového hostovaného kontejneru, dev Containers mají plnou 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 najdete příliš omezující kontejnery, podpora SSH v nástrojích, jako jsou VS Code nebo Nástroje JetBrains, jako je IntelliJ, vám umožní přímé připojení k virtuálním počítačům s Linuxem, které spravujete sami. VS Code nabízí také možnost založenou na tunelu.
Použití Subsystém Windows pro Linux	Pokud jsou vaši vývojáři výhradně ve Windows, Subsystém Windows pro Linux (WSL) je skvělým způsobem, jak 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é. V případě cloudové možnosti můžou služby cloudových pracovních stanic, jako je Microsoft Dev Box, využít také WSL k cílení vývoje pro Linux.

Vytvoření správných šablon aplikací, které obsahují správnou konfiguraci

Skvělá věc o všem, jak je vzor kódu, je, že může vývojářům udržet na zpevněných cestách, které jste vytvořili od začátku. Pokud se jedná o výzvu pro vaši organizaci, šablony aplikací se můžou rychle stát kritickým způsobem, jak znovu použít stavební bloky pro zajištění konzistence, zvýšení standardizace a kodifikování osvědčených postupů vaší organizace.

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

Jakmile máte sadu šablon, můžou vývojáři využít tyto nástroje příkazového řádku nebo jiná integrovaná uživatelská prostředí k vygenerování jejich 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 použít ručně aktivované, parametrizované pracovní postupy nebo kanály. Vstupy můžete nastavit tak, aby systém CI/CD vytvořil cokoli z úložiště do infrastruktury jejich jménem.

Zůstat v pořádku a dostat se doprava

Aby však tyto šablony aplikací pomohly škálovat, měly by odkazovat na centralizované stavební bloky( například šablony IaC nebo dokonce pracovní postupy CI/CD / kanály). Zacházení s těmito centralizovanými stavebními bloky jako s jejich vlastní formou počátečních správných šablon může být efektivní strategií pro řešení některých zjištěných problémů.

Každá z těchto jednotlivých šablon se dá použít nejen pro nové aplikace, ale i stávající šablony, které chcete aktualizovat jako součást správné kampaně pro zavedení aktualizovaných nebo vylepšených pokynů. Ještě lepší je, že tato centralizace vám pomůže udržet si nové i stávající aplikace správné, abyste mohli v průběhu času vyvíjet nebo rozšiřovat osvědčené postupy.

Obsah šablony

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

Plocha	Detaily
Dostatečný zdrojový kód ukázky pro řízení vzorů aplikací, sad SDK a použití nástrojů	Zahrňte kód a konfiguraci pro vývojáře směrem k doporučeným jazykům, modelům aplikací a službám, rozhraním API, sadám SDK a vzorům architektury. Nezapomeňte zahrnout kód pro distribuované trasování, protokolování a pozorovatelnost pomocí zvolených nástrojů.
Vytváření a nasazování skriptů	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í nebo editoru pro nástroje, které si můžete vybrat, abyste je mohli používat. Je to důležitý způsob, jak se vyhnout bolesti hlavy při údržbě a zabránit tomu, aby ci/CD přestala být synchronizovaná. Pokud se modul šablony domnívá, jako je Rozhraní příkazového řádku azure pro vývojáře, můžou už existovat příkazy, které můžete použít.
Konfigurace pro CI/CD	Poskytuje 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, které vám pomůžou udržovat je v aktualizovaném stavu. Tyto opakovaně použitelné pracovní postupy nebo kanály můžou ve skutečnosti začínat vlastními šablonami. Nezapomeňte zvážit možnost ručního spuštění těchto pracovních postupů.
Infrastruktura jako prostředky kódu	Poskytovat doporučené konfigurace IaC včetně odkazů na centrálně spravované moduly nebo položky katalogu, aby se zajistilo, že jakékoli nastavení infrastruktury dodržuje osvědčené postupy z get-go. Tyto odkazy také můžou týmům pomoct udržet správný čas. V kombinaci s pracovními postupy nebo kanály můžete také zahrnout IaC nebo EaC, abyste zřídili cokoliv.
Zabezpečení a zásady jako prostředky kódu	Přesun DevSecOps přesunul konfiguraci zabezpečení do kódu, což je skvělé pro šablony. Některé zásady jako artefakty kódu lze použít také na úrovni aplikace. Zahrnout jako všechno od souborů, jako je CODEOWNERS, až po skenování konfigurace, jako je dependabot.yaml v GitHub Advanced Security. Poskytněte naplánované pracovní postupy nebo spuštění kanálu pro kontroly pomocí něčeho, jako je Defender for Cloud , spolu s testovacími běhy prostředí. To je důležité pro zabezpečení dodavatelského řetězce a nezapomeňte kromě balíčků aplikací a kódu zahrnout i image kontejnerů. Tyto kroky pomáhají vývojových týmům zůstat v pořádku.
Pozorovatelnost, monitorování a protokolování	Součástí povolení samoobslužné služby je snadný přehled o aplikacích po nasazení. Kromě infrastruktury modulu runtime nezapomeňte zahrnout nastavení pro pozorovatelnost a monitorování. Ve většině případů existuje aspekt nastavení IaC (například nasazení agenta, instrumentace), zatímco v jiných případech se může jednat o jiný typ artefaktu kódu jako konfigurace (například monitorování řídicích panelů pro Aplikace Azure lication Insights). Nakonec nezapomeňte zahrnout vzorový kód kódu pro distribuované trasování, protokolování a pozorovatelnost pomocí zvolených nástrojů.
Nastavení prostředí kódování	Zahrňte konfigurační soubory pro kódování linterů, formátovacích nástrojů, editorů a prostředí IDE. Zahrnout instalační skripty spolu s virtualizačními soubory pracovního prostoru nebo pracovní stanice, jako jsou devcontainer.json, devbox.yaml, soubory Docker Compose nebo soubory Vagrantfiles zaměřené na vývojáře.
Testovací konfigurace	Poskytněte konfigurační soubory pro testování jednotek i podrobnějšího testování pomocí preferovaných služeb, jako je Microsoft Playwright Testing pro uživatelské rozhraní nebo Zátěžové testování Azure.
Nastavení nástroje pro spolupráci	Pokud váš systém správy problémů a správy zdrojového kódu podporuje úlohy / problém / šablony PR jako kód, zahrňte je také. V případech, kdy se vyžaduje další 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.