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

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 integruje se do tohoto procesu s průběžnými postupy zabezpečení během procesu vývoje aplikací.

Diagram ž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řipisovaná hnutí platformového inženýrství: usnadněné cesty, automatizované poskytování infrastruktury (kromě nasazení aplikací), nastavení prostředí kódování spolu se samoobslužným poskytováním a konfigurací nástrojů, týmových aktiv a služeb, které nejsou přímo součástí cyklu vývoje aplikací.

Zřiďte požadované zpevněné cesty

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 stále 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. Jak to vyjádřil jeden z vedoucích inženýrů platformy:

Pořád si můžete udělat vlastní věc, ale zkuste to udělat ve směru, kterým směřujeme... můžete změnit, co chcete, ale to se stane vaší zodpovědností. Máte na starosti změny – máte na starosti 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 inženýrství platforem je přechod na myšlení zaměřené na produkt, kde poskytujete hodnotu interním zákazníkům, tento přístup konstelace obvykle funguje lépe než mandát shora dolů. Při vytváření a upřesňování zpevněných cest ponechání určité flexibility umožňuje týmům přidávat své názory a řešit opravdu unikátní požadavky pro danou aplikaci, aniž by to ovlivnilo jiné procesy 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, další vývoj práce, který týmy provádějí 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 náročnější, než očekáváte. Proto je na začátku pravděpodobně lepší se zaměřit na to, jak správně začít v této oblasti, a soustředit se na nové projekty. To poskytuje první zpevněnou cestu, zatímco všechno, co existuje, je přirozeně nezpevněné. Vývojové týmy na nezpevněné cestě pak můžou zvážit přesun, jakmile nová zpevněná cesta prokáže svou hodnotu pro organizaci. V tomto okamžiku můžete zahájit kampaň pro dosažení požadovaného stavu prostřednictvím obousměrné komunikace, protože vývojové týmy vidí tuto iniciativu jako přínos spíše než jako zátěž. 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.

Vyhněte se požadování používání svých zpevněných cest. Nejúčinnějším způsobem, jak zavést zpevněné cesty, je zdůraznit, co z nich týmy získají, spíše než skrze vynucené 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ískat ty správné kampaně a pak poskytnout možnost obousměrných konverzací jako nejlepší způsob pro ty, kteří jsou na nevyzpytatelné cestě k přechodu.

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í, pravděpodobně odkazují 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.

Představte si například následující ilustrace, které znázorňují 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í (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 relativně nový a je populární mezi organizacemi, které používají Kubernetes jako základ svých aplikací. Model založený na principu "pull" 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, můžete se naučit 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 radius nebo chartech Helm uložených v cloudovém nativní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 CAPZ) umožnit správu clusterů úloh Kubernetes, zatímco vlastní definice prostředků, jako je operátor služby Azure , můžou poskytnout přidanou podporu pro další druhy prostředků Azure. Další nástroje, jako je Crossplane , podporují prostředky napříč několika cloudy. Díky těmto kartám můžete použít centralizované nebo společné Helmovy karty v něčem 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í inkubační projekt Radius OSS jsou více předem definované než přímé použití Kubernetes, ale také zefektivňují vývojářské prostředí. Další informace o výhodách a nevýhodách různých modelů najdete v tématu Popis typů cloudových služeb. 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 klíčů tak, aby k nim vývojáři neměli přímý přístup, vytváří základní stavební kameny pro zásady 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 pomoci bezpečně a spolehlivě aktualizovat infrastrukturu tím, že oddělí tajné klíče a získává obsah IaC z míst, ke kterým vývojáři nemají přístup a kde je nemohou 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 značné úsilí?
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 od požadavků na audit Vašeho systému pro řízení verzí?
Existují procesy, se kterými můžete začít s nižším rizikem, než přejdete na složitější procesy?

Identifikujte časté procesy, vysoce náročné procesy 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 ustanovit konkrétní posuzovatele, historii diskuzí nebo automatizované kontroly, které musí být splněny před sloučením do hlavní větve. 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é clustery Kubernetes 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 nebo Terraformu až po charty Helm a další nativní formáty Kubernetes). Provozní tým nebo jiní správci vlastní úložiště a vývojáři (nebo systémy) mohou odesílat pull requesty. 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í. Zvažte následující ilustraci, která znázorňuje identity GitHub Actions, IaC a nasazení umístěné v Azure Deployment Environments.

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í, a to i v případě, že to, co se vytváří, není pro aplikaci. Stejně jako u vývoje aplikací se veškerá tajemství nebo spravované identity, které potřebujete, ukládají do engine pipeline/workflow nebo do nativních funkcí provisioningové služby.

Vzhledem k tomu, že lidé, kteří vytvářejí žádosti o přijetí změn, nemají přímý přístup k těmto tajným informacím, poskytuje to vývojářům způsob, jak bezpečně zahájit 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. Pokud ale budete používat přístup 'vše jako kód', získáte zdroj informací, který vám umožní vytvořit přehled zřízené infrastruktury. Váš poskytovatel může být také dobrým zdrojem těchto informací, ke kterým můžete mí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 zřizování infrastruktury užitečné, je stejně důležité zajistit, aby byla tato prostředí zabezpečená a obecně se řídila zásadami vaší organizace. To vedlo k nárůstu konceptu politik jako kód. Tady můžete konfigurační soubory v úložišti správy zdrojového kódu použít k provedení akcí, jako je kontrola zabezpečení jednotky nebo použití zásad infrastruktury.

Tento přístup přijal mnoho různých produktů a opensourcových projektů, včetně Azure Policy, agenta Open Policy, 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.

Využijte vše jako kód pro své vlastní scénáře

Vše 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.

Pull request se stává dobrým základním uživatelským zážitkem samoobslužné služby 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é jsou součástí, se také můžou v průběhu času měnit, aniž by to mělo vliv na uživatelské prostředí.

Týmy jako kód

Jedním z příkladů aplikace konceptu "vše jako kód" na vaše vlastní scénáře je vzor "týmy jako kód". 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 přihlašování a odhlašování na servisní pult, které jsou řízené potřebou vývojářů a operátorů systémů pro přístup k vlastním skupinovým strukturám, uživatelům a přístupovým konceptům. Ruční procesy servisních přepážek představují potenciální bezpečnostní riziko, protože je možné nadměrně poskytnout 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 auditovatelných dat.

Příklad zralé a rozsáhlé varianty tohoto vzoru si můžete prohlédnout v blogovém příspěvku GitHubu o tom, jak spravují oprávnění. GitHub také otevřel svůj sofistikovaný systém implementace přístupových práv, který 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ý zúčastněný systém byl nastaven tak, aby používal vašeho zprostředkovatele identity (například Microsoft Entra ID) pro jednotné přihlášení (SSO).
Ke správě členství podle role používáte skupiny zprostředkovatelů identit (například skupiny Entra) napříč systémy, 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 a schvalovatelé změn v týmu mohou být také uloženi na stejném místě (například pomocí 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 pull requestů. Tím se konverzace a související účastníci propojují s potvrzením v Gitu pro účely auditovatelnosti.
Vedoucí a jednotliví uživatelé můžou vytvářet pull requesty na přidání nebo odebrání lidí, a vedoucí vývoje a další role mohou vytvářet nové týmy pomocí pull requestů s novým týmovým souborem z š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 vhodné API systému poskytovatelů identity k vytvoření nebo aktualizaci skupiny podle role s přesně těmi osobami, které jsou v souboru (přesně, ne více ani méně).
Používá rozhraní API pro každý podřízený systém ke svázání konceptu seskupení systémů s identifikací skupin poskytovatelů pro každou roli (například GitHub a Azure DevOps). Tím může vzniknout vztah 1:N mezi vaším týmem a podřízeným systémem, který se používá k reprezentaci role.
(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 všechny interně sestavené systémy. 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 správa nároků Entra, 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 nebo 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 jsou pravděpodobně seznámeni s těmito uživatelskými prostředími, můžou ruční spouštěče rozšířit vzor vše jako kód, což umožňuje automatizaci aktivit (nebo úloh), které nemají přirozenou reprezentaci souborů nebo by měly být plně automatizovány bez vyžadování procesu PR.

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. Například tohle je způsob, jakým portálové sady nástrojů, jako je Backstage.io, interagují 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 vzor 'vše jako kód'. Mějte ale na paměti, že všechny akce prováděné těmito pracovními postupy nebo kanály se pro podřízené systémy jeví jako systémová identita (například služební objekt nebo spravovaná identita v Microsoft Entra ID).

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 dostanou k prvnímu pull requestu. Jedná se o problematickou oblast, když přesouváte vývojáře mezi týmy funkcí a projekty poměrně často (například v maticových organizacích), potřebujete zapojit více dodavatelů, nebo jste v týmu ve fázi náboru.
Nekonzistence mezi vývojáři a systémy kontinuální integrace může vést k častým problémům typu "funguje to na mém počítači", a to i pro zkušené č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.
Pro vedoucí vývojových týmů mohou revize kódu zpomalit vývoj, protože mohou vyžadovat změnu konfigurace pro testování a její vrácení zpět po dokončení revize.
Členové týmu a operátoři také musí trávit čas tím, že se věnují souvisejícím rolím nad rámec vývoje (operátoři, kontrola kvality, obchodní role, sponzoři), aby pomohli testovat, sledovat průběh, trénovat obchodní role a propagovat práci, kterou tým dělá.

Část vašich zpevněných cest

Pokud chcete tyto problémy vyřešit, zamyslete se nad nastavením konkrétních nástrojů a utilit jako součást dobře definovaných vyšlapaných cest. Nastavení vývojářského počítače pro skriptování 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	Examples
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 více než na nahrazení plochy pro vývojáře zaměřují na pracovní prostory specifické pro projekt nebo aplikaci.

Přístup	Examples
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 s Dev Containers na vzdálených Linuxových virtuálních počítačích využít podporu SSH nebo vzdálených tunelů ve VS Code. Možnost založená na tunelu, která funguje nejen s klientem, ale i s webovým rozhraním vscode.dev.
Použití místních kontejnerů	Pokud dáváte přednost místní možnosti Dev Containers nebo navíc ke cloudové hostované možnosti, Dev Containers mají solidní podporu v 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 má také možnost založenou na tunelu .
Použití subsystému Windows pro Linux	Pokud jsou vaši vývojáři výhradně ve Windows, je subsystém Windows pro Linux (WSL) 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řte šablony aplikací pro správný start, které zahrnují správné nastavení

Skvělá věc na vzoru vše jako kód je, že může udržet vývojáře na zpevněných cestách, které jste stanovili 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 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 váš systém CI/CD vytvořil cokoli od úložiště po infrastrukturu v jejich zastoupení.

Zůstat správný a napravit věci

Pro usnadnění škálování by však tyto šablony aplikací měly odkazovat na centralizované stavební bloky, pokud je to možné (například šablony IaC nebo dokonce pracovní postupy CI/CD a 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.

Area	Podrobnosti
Dostatečné množství zdrojového kódu ukázky pro podporu vzorů aplikací, SDK a využ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 provést místní a sandboxové nasazení. Zahrňte konfiguraci ladění v integrovaném vývojovém prostředí nebo editoru pro vaše preferované nástroje, abyste je mohli používat. Je to důležitý způsob, jak se vyhnout problémům s údržbou a zabránit tomu, aby CI/CD nebylo synchronizováno. Pokud je váš engine pro šablony s předem definovanými názory, jako je například Azure Developer CLI, mohou už existovat příkazy, které můžete přímo 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žet je up-to-date. 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 bylo zajištěno, že jakékoli nastavení infrastruktury dodržuje osvědčené postupy od samého začátku. Tato doporučení také můžou týmům pomoct udržet správný směr, jak čas ubíhá. V kombinaci s pracovními postupy nebo kanály můžete také zahrnout IaC nebo EaC, abyste mohli zřídit prakticky 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 kód lze použít také na úrovni aplikace. Zahrnout vše od souborů, například CODEOWNERS, až po konfigurace skenování, jako je dependabot.yaml v GitHub Advanced Security. Poskytněte naplánované pracovní postupy a spouštění kanálů 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ým týmům držet se na správné cestě.
Pozorovatelnost, monitorování a protokolování	Částí povolení samoobslužnosti je zajištění snadné přehlednosti aplikací po jejich 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 Azure Application 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 lintery, formátory, editory a prostředí IDE. Zahrnout instalační skripty spolu s virtualizačními soubory pracovního prostoru nebo pracovní stanice, jako devcontainer.json, devbox.yaml, Dockerfiles zaměřené na vývojáře, soubory Docker Compose, nebo Vagrantfiles.
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 Testování aplikací 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.

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-10-23