Návrh samoobslužného základu pro vývojáře
Jakmile dobře pochopíte svůj cíl pro technické systémy, můžete vytvářet sofistikovanější samoobslužné prostředí pro vývojáře. Samoobslužné prostředí pro vývojáře je založené na základech konceptů, vzorů a komponent.
I když už možná nebudete potřebovat všechno popsané v organizaci, měli byste mít na paměti tyto koncepty, pokud vytváříte něco vlastního nebo vyhodnocujete související produkty. Model samoobslužného prostředí pro vývojáře se může skládají z kombinace domácích produktů, mimo police a opensourcových produktů. Produkty nebo opensourcové sady nástrojů portálu, jako je Backstage.io , můžou pro některé prvky níže popsaného modelu používat různé termíny, ale model vám může pomoci se orientovat.
Automatizace pracovních postupů, agregace dat, zahájení jednoduchého a postupného rozbalení
Vaším cílem je umožnit samoobslužné služby s mantinely prostřednictvím řízeného, řízeného spouštění a zřizování úkolů a centralizovaného viditelnosti. Oblasti, na které je nejdůležitější zaměřit se, jsou ty, které jsou buď zdlouhavé, nebo jsou věci, které vývojář nemůže udělat sami kvůli složitosti nebo oprávněním. Tato poslední část je důležitá, abyste mohli postupovat podle principu nejnižších oprávnění bez vynucení vývojářů prostřednictvím ručního procesu servisního oddělení.
I když se můžete rozhodnout rozšířit sadu DevOps tak, aby vyhovovala těmto potřebám, budete pravděpodobně muset v průběhu času podporovat více aplikačních platforem a konkrétní nástroje a procesy, které je podporují, se budou muset také změnit. Základním problémem je, že vaše standardy představují směrný cíl. Jako jeden technický pracovník platformy uvedl:
Potíže zahrnují standardizaci ... a jednání s 'abandonware'... Standardizace se často nedosáhne kvůli potenciálnímu přerušení automatizovaných procesů a časově náročnému úkolu identifikace nezbytných změn. - Martin, technik DevOps, velká logistická společnost
Rychlé přepnutí na nový nebo aktualizovaný standard obvykle není možné a opuštění stávajících procesů vytváří riziko. Vaše organizace už možná ve scénáři používá několik sad DevOps nebo různé kombinace jednotlivých nástrojů a vývojářských služeb. I s centrálním týmem a standardním řešením, protože vaše samoobslužné potřeby se zvyšují, je proměnlivost nevyhnutelné. Proto budete chtít povolit řízené experimentování, kde by určené týmy mohly vyzkoušet nové technologie, strategie nasazení atd., následované záměrným přechodem a přírůstkovým zaváděním.
Obecně platí, že samoobslužná prostředí spadají do dvou primárních kategorií: automatizace a agregace dat.
I když agregace dat vytváří dobré uživatelské prostředí, je automatizace důležitější:
Automatizace je klíčová a bude ji milovat každý. Agregace [Data] je sekundární. – Peter, vedoucí inženýrských platforem, nadnárodní technická společnost
Na cestě k technikům platformy jste identifikovali problémy, které by mohly být vyřešeny automatizací. Kromě omezení kognitivního zatížení a toilu vývojářů může automatizace také pomoct zajistit, aby aplikace byly připojené k nejlepším nástrojům a službám pro provoz, zabezpečení a další role, aby mohly provádět svou práci.
Pokud ale pracujete s více než jedním systémem pro řízení automatizace, je určitá úroveň agregace dat užitečná ke sledování automatizovaných požadavků a přidružených výsledků. Můžete začít propojením s externími systémy, které splňují jiné potřeby nebo podrobné informace. Agregace a viditelnost dat je také důležitá pro auditování, zásady správného řízení a snížení plýtvání (příklad: nevyužitá prostředí).
Automatizaci věcí, jako je zřizování infrastruktury, je možné provádět pomocí systémových integrací, ale můžete také aktivovat a usnadnit ruční proces pracovního postupu, který vypadá automaticky pro vývojáře. To je užitečné v počátečních fázích vaší platformy, pro nové produkty, které přinášíte do ekosystému, nebo v oblastech, které nemáte nebo nemůžete automatizovat pomocí systému (například přiřazení licencí softwaru). Se správným návrhem můžete začít ručním procesem, který vám usnadní power automate, který v průběhu času přepnete na plně automatizovaný tok. Proto navrhujte automatizaci od začátku.
Začněte jednoduše tím, že znovu používáte stávající investice, jako jsou vaše technické systémy nebo interní portál, pak vytvoříte rozhraní CLI, základní webové stránky, nebo dokonce Power Pages, Power BI nebo řídicí panely Microsoft Fabric a rozšíříte se podle potřeby. Konzistentní rozhraní API, které pak používá uživatelské rozhraní, vám může pomoct podporovat více rozhraní v průběhu času, protože se mění vaše potřeby a předvolby.
Komponenty samoobslužné platformy pro vývojáře: rozhraní API, graf, orchestrátor, poskytovatelé a metadata
Zvažte základy samoobslužných služeb pro vývojáře:
Jak je znázorněno na obrázku, následující komponenty tvoří jádro konceptu samoobslužného základu vývojáře:
| Komponenta | Popis |
|---|---|
| Rozhraní API platformy pro vývojáře | Toto je váš jediný kontaktní bod pro uživatelská prostředí. Je to v podstatě kontrakt systému s jinými systémy. |
| Graf platformy pro vývojáře | Spravovaný a zabezpečený datový graf, který umožňuje zjišťovat, přidružit a používat různé druhy entit a šablon. Entita je objekt, který umožňuje agregaci dat z více zdrojů, zatímco šablony řídí vstupy uživatelů, které umožňují automatizaci. |
| Orchestrátor vývojářské platformy | Schopnost, která směruje a sleduje požadavky založené na šablonách, aby prováděly akce v systému nebo prostřednictvím ručního procesu. Tyto požadavky se směrují na jednu ze sady poskytovatelů vývojářské platformy, kteří se můžou integrovat do libovolného počtu různých systémů pracovních postupů nebo jiných služeb. |
| Poskytovatelé vývojářských platforem | Sada komponent, které zapouzdřují logiku potřebnou k integraci s podřízenými systémy, aby podporovaly operace CRUD s entitami nebo plnění požadavků na akce založené na šablonách. Každý poskytovatel může podporovat vlastní konkrétní typ šablon a generovat jedinečné nebo běžné typy entit. |
| Profil uživatele a metadata týmu | Schopnost uchovávat informace o sadě jednotlivců svázaných s koncepčním týmem pro seskupování a přístup k rozhraní API platformy pro vývojáře. Uživatel je úzce spojený s účtem zprostředkovatele identity (například přihlášením k Microsoft Entra ID), ale tým může svázat libovolný počet souvisejících reprezentací podřízeného systému. Jednou z implementací tohoto úložiště informací je opětovné použití grafu vývojářské platformy. Samoobslužné základy pro vývojáře můžou vytvořit společný typ entity pro uživatele i tým a zachovat informace v grafu. Toto úložiště ale budeme kvůli přehlednosti udržovat oddělené. |
Tyto základní komponenty umožňují používat a prohodit různé stavební bloky v průběhu času.
Musím všechno vytvořit, abych mohl začít?
Ne. Nejprve se jedná o koncepční model, který vám pomůže promyslet si, co by mělo být po dokončení základního modelu možné udělat. Za druhé, specifika implementace jsou zde méně důležitá vzhledem k tomu, že rozhraní API platformy pro vývojáře se stane vaším klíčovým rozhraním. Vaše počáteční implementace může začít používat rozhraní a třídy v kódu pro různé vrstvy popsané nebo kombinovat v jiných produktech. Můžete také vynechat aspekty, protože vývoj vašich zákazníků vám říká, že je to jednoduše nižší priorita. Začněte tím, co máte a rostete.
Rozhraní API platformy pro vývojáře
Měli byste definovat rozhraní API platformy pro vývojáře, které bude fungovat jako kontrakt vašeho systému. Rozhraní API používá různá uživatelská rozhraní k povolení přístupu k datům nebo zřizování jednotek a dalších akcí.
Toto rozhraní API funguje jako důležitá vrstva ověřování a zabezpečení tím, že omezuje přístup k nezpracovaným podkladovým rozhraním API v jiných systémech na konkrétnější, kontrolovaná data a operace. Rozhraní API poskytuje přístup k vlastní reprezentaci profilu uživatele, vysoké roli uživatele v rámci platformy (člen týmu, správce atd.) a identifikátorů systému primárního zprostředkovatele identity. Další informace najdete v tématu Uživatelé a týmy.
Poskytovatelé vývojářských platforem
Vzhledem k šíři interní vývojářské platformy, vytváření nebo identifikaci systémů, které následují podle modelu rozšiřitelného poskytovatele, zavádějí do rozhraní API funkce. Myšlenka spočívá v tom, že klíčové funkce, jako je automatizace a agregace dat, poskytuje interakce s připojitelnými komponentami s dobře definovanými rozhraními. Tato volná spojka pomáhá drátovat v tom, co potřebujete, a zlepšuje udržovatelnost, protože můžete testovat funkčnost nezávisle na zbytku základu.
Je to také důležitý způsob, jak pro vaši platformu umožnit škálovatelnou vnitřní zdrojovou telemetrii. Úsilí o vnitřní vytváření platforem obvykle nedokáže získat trakci kvůli problémům s průběžnou údržbou. Ostatní týmy můžou být ochotni přispívat funkcemi, ale méně pravděpodobné je, že budou ochotni udržovat a testovat něco uvnitř jádra vaší platformy. Naopak každý centralizovaný tým má omezenou kapacitu pro zachování kódu, ke které přispěl, nebo dokonce ke kontrole žádostí o přijetí změn. Koncept poskytovatele vývojářské platformy toto napětí snižuje tím, že umožňuje nezávisle napsaný kód "připojit" k základním funkcím v rámci samoobslužné nadace vývojáře. I když byste měli pečlivě spravovat, které poskytovatele používáte, projděte si veškerý kód zprostředkovatele a omezte povrchovou oblast, ke které má daný poskytovatel přístup ve vaší vývojářské platformě, může vám pomoct více práce škálováním úsilí v širší části organizace.
Klíčové koncepty poskytovatelů vývojářské platformy
Entity
Koncept entity je něco, co vývojář nebo jiný systém ve vaší interní vývojářské platformě potřebuje sledovat, aktualizovat, prezentovat nebo reagovat. Entity můžou mít vztahy mezi sebou, které při vzájemném vytvoření grafu, který poskytuje důležité informace o částech vaší interní vývojářské platformy. Poskytovatelé vývojářské platformy pak můžou výstupní entity, které umožní základní funkce, včetně následujících:
- Zpřístupnění externě zřízených prostředků / prostředí nebo dostupných rozhraní API pro zjišťování a použití
- Zveřejnění relací pro analýzu závislostí, analýzu dopadu, zjišťování atd.
- Zpřístupnění informací o správci / vlastnictví pro zjišťování a spolupráci
- Zpřístupnění dalších dat pro použití v uživatelských prostředích
Zapouzdření této funkce do dobře definovaného rozhraní poskytovatele vývojářské platformy zjednodušuje integraci a testování, umožňuje nezávislé nasazení a umožňuje vývojářům mimo primární interní tým vývojářských platforem přispívat a spravovat poskytovatele. To je důležité v rozsáhlých nebo divizních organizacích, kde se ne každý nástroj, služba nebo platforma spravují centrálně, ale širší organizace stále chce sdílet možnosti. Takže i když tuto cestu zpočátku nezatáhnete, je to něco, o čem byste se měli zamyslet v dlouhodobém horizontu.
Obecné vlastnosti
Každá entita by měla mít sadu společných vlastností, aby je nadace mohla spravovat. Mezi vlastnosti, které je potřeba zvážit, patří:
- Jedinečný identifikátor
- Název
- Původní zprostředkovatel
- Volitelná přidružení k:
- Vlastnící uživatel
- Vlastnící tým
- Jiné entity
Vlastnosti uživatele a týmu jsou důležité ze tří důvodů: řízení přístupu na základě role (RBAC), zjišťování a agregace dat (například souhrny na úrovni týmu). Sestavování v RBAC od začátku je důležité pro zabezpečení a růst interní vývojářské platformy v průběhu času. Vzhledem k tomu, že vývoj je týmový sport, zjistíte, s kým si o entitě popovídat, se rychle stane kritickým pro opakované použití, podporu a vnitřní využití.
Běžné entity a entity specifické pro zprostředkovatele
Měli byste být také schopni vytvořit sadu běžných vysoce výkonných normalizovaných entit, které mohou vytvářet více poskytovatelů. Příklad:
- Prostředí
- Zdroje informací
- Rozhraní API
- Úložiště
- Komponenty
- Nástroje
Ty by měly být obecně na vysoké úrovni, jako byste umístili do kontextu modelu C4 nebo na nejvyšší úrovni diagramů komponent. Například pro prostředí nemusíte obsahovat podrobnosti o topografii interní infrastruktury: Potřebujete jenom dostatek informací k výpisu a přidružení různých koncepčních prostředí od více poskytovatelů ve stejném uživatelském prostředí. Entita může odkazovat na nižší úrovně podrobností mimo systém, místo aby se snažila využívat všechno. Ty poskytují výchozí body pro zjišťování, které jsou centrální pro povolení agregace dat v průběhu času.
Ostatní budou specifické pro konkrétní případ použití nebo poskytovatele, takže byste měli přemýšlet o tom, jak můžete v průběhu času pojmout rostoucí sadu typů entit.
Šablony
Koncept šablony v tomto kontextu se liší od myšlenky entit v tom, že jsou určeny k řízení akce. Mezi příklady scénářů patří zřizování infrastruktury, vytvoření úložiště a další dlouhotrvající procesy. Tyto šablony by měly být dostupné také prostřednictvím rozšiřitelných poskytovatelů vývojářských platforem a měly by podporovat stejné společné vlastnosti jako entity – včetně přidružení entit.
Mohou však také definovat požadované vstupy, ať už zadaný systém nebo uživatel, které jsou potřeba k provedení akce. Tyto možnosti můžou být v rozsahu od pojmenování prostředku až po volitelné doplňky.
Mezi příklady šablon patří:
- Šablony infrastruktury jako kódu (IaC)
- Šablony aplikací (začít vpravo) nebo úložiště šablon
- Kanál sestavení / šablony pracovních postupů
- Kanál nasazení / šablony pracovních postupů
- Parametrizované skripty
- Parametrizované toky Power Automate (příklad: požadavek HTTP aktivovaný cloudovým tokem)
- Šablony e-mailů
Podobně jako entity můžou šablony zahrnovat vlastnosti specifické pro zprostředkovatele.
Každá šablona může mít jinou reprezentaci, která je pro poskytovatele jedinečná. Můžou se lišit od terraformu nebo šablon ARM až po charty Helm, parametrizované pracovní postupy GitHub Actions nebo Azure Pipelines, jednoduché skripty nebo vlastní formáty.
Skutečné podrobnosti podkladové šablony nemusí být nutně uložené centrálně. Můžou existovat v různých úložištích, registrech nebo katalogech. Můžete například použít úložiště šablon GitHubu pro šablony vaší aplikace, zatímco šablony IaC můžou existovat v úložišti s omezeným katalogem, ke kterému můžou vývojáři přistupovat jenom nepřímo prostřednictvím něčeho jako prostředí nasazení Azure. Další šablony IaC můžou být uložené v registru artefaktů OCI, jako jsou grafy Helm. V jiných případech může být šablona odkazem na parametrizovaný koncový bod HTTP. Poskytovatel vývojářské platformy by měl poskytnout dostatek informací o jednotlivých typech šablon, aby na nich bylo možné odkazovat, a všechny dostupné možnosti pro použití v uživatelských prostředích. Ale samotné šablony mohou být umístěny v nejpřirozenější lokalitě pro vaše případy použití.
Inženýři platformy nebo odborníci na konkrétní oblast píší šablony a pak je sdílejí s vývojářskými týmy pro opakované použití. Centralizace používání těchto šablon prostřednictvím systému umožňuje vývojářům samoobslužnou službu a vytváří mantinely, které pomáhají vynucovat dodržování standardů organizace nebo zásad. Více o tom, když se trochu podíváme na orchestrátor vývojářské platformy.
Graf platformy pro vývojáře
Graf platformy pro vývojáře si můžete představit jako něco, co umožňuje přidružit entity a šablony od více poskytovatelů do prohledávatelného grafu. Skutečná data entit ale nemusí být nutně uložená přímo v databázi specifické pro grafy. Místo toho by se interakce s zprostředkovateli mohly ukládat do mezipaměti spolu s potřebnými metadaty, aby se všechny vešly dohromady.
Graf je výkonný při použití s běžnými entitami, které může přispívat více poskytovatelů. Například seznam rozhraní API může pocházet z produktu, jako je Azure API Center, ale můžete také chtít automaticky nasčítat v nasazeních a prostředích ze systémů průběžného nasazování. V průběhu času můžete přepínat mezi různými systémy nasazení nebo dokonce podporovat více než jeden systém nasazení. Pokud má každý systém nasazení poskytovatele vývojářské platformy, měli byste být stále schopni vytvořit přidružení.
Každá z vašich uživatelských prostředí, která se z tohoto grafu sestavují, pak může využívat společné rozhraní API k výkonu zjišťování, vyhledávání, zásad správného řízení a dalších možností. Orchestrátor vývojářské platformy pak může využít stejný graf, aby všechny akce prováděné poskytovatelem vývojářské platformy automaticky přispěly k entitám dostupným do stejného rozhraní API.
Orchestrátor vývojářské platformy
Orchestrátor vývojářské platformy umožňuje vývojářům nebo systémům vytvářet požadavky na provedení akce pomocí šablony. Tyto akce neprovádí sám, ale koordinuje to s modulem úloh, modulem pracovního postupu nebo jiným orchestrátorem. Je to jeden z důležitých částí, které budete chtít mít jistotu, že je součástí vašeho samoobslužného základu. Umožňuje vývojářům vytvářet žádosti pomocí šablony nebo spouštět akci bez přímého oprávnění. Na rozdíl od konceptu CI nebo CD navíc tyto akce nemusí souviset se zdrojovým kódem aplikace.
Jako orchestrátor můžete použít GitHub Actions, Azure Pipelines nebo jiný modul pracovního postupu. Toto je rozumné místo, kde začít, ale možná budete chtít mít trochu abstrakce, abyste umožnili různým typům šablon používat různé podkladové moduly. To může být užitečné z několika důvodů:
- Nejprve budete pravděpodobně chtít vybrat různé pracovní postupy a moduly pro provádění úkolů v průběhu času, aniž byste museli blikat. Povolením více než jednoho modulu můžete migrovat v průběhu času nebo jednoduše použít nový modul na nové akce, aniž by to mělo vliv na starší.
- Některé procesy, které chcete pomoct s orchestraci, můžou zpočátku vyžadovat ruční kroky, i když je plánujete plně automatizovat později.
- Další akce můžou cílit na role mimo vývojový tým, jako jsou účty splatné nebo správce licencí. Moduly s nízkým kódem, jako je Power Automate, často dobře fungují pro tyto role.
- Jiné akce se můžou zpracovávat prostřednictvím jednoduchých požadavků HTTP, kde se může něco jako GitHub Actions nebo Azure Pipelines zpracovat, protože škálování není nutné ani nákladově efektivní.
Rozšířením představy poskytovatele vývojářské platformy, který se naštěstí zaměřuje na aktivaci a sledování kroků automatizace, může poskytnout tuto potřebnou abstrakci. Představte si následující obrázek:
Tady je obecný koncept:
- Šablony můžou volitelně zadat sadu vstupů, které může uživatel zadat. Když vývojář aktivuje určitou akci, vybere šablonu (i když tak není popsáno) a zadá všechny vstupy.
- Odkaz na vstupy související se šablonou se stane požadavkem v rozhraní API platformy pro vývojáře.
- Po odeslání požadavku začne komponenta směrování a zpracování požadavků v orchestrátoru sledovat životní cyklus požadavku. Šablona směrování požadavků a zpracování tras komponent v požadavku poskytovateli vývojářské platformy, odkud šablona pochází.
- Poskytovatel vývojářské platformy pak provede příslušné kroky pro její implementaci.
- (Volitelné) Poskytovatel vývojářské platformy aktualizuje stav žádosti při provádění akce.
- Po splnění požadavku může poskytovatel vývojářské platformy vrátit sadu entit, které se mají přidat nebo aktualizovat v grafu platformy pro vývojáře. Můžou to být konkrétní zprostředkovatelé nebo běžné entity.
Pokud chcete podporovat pokročilejší interakce, můžou poskytovatelé vývojářských platforem volat rozhraní API platformy pro vývojáře přímo, aby získali více entit jako vstupy nebo dokonce požádali o další související akci.
Vyberte poskytovatele vývojářské platformy, který používá obecný úkol nebo modul pracovních postupů. Konkrétně chcete, aby něco přemostěly to, co jste sestavili jako součást použití softwarových inženýrských systémů. Jedním z obecných pracovních postupů nebo modulu provádění úkolů, který se má investovat, je systém CI/CD.
Příklad použití GitHub Actions nebo Azure Pipelines
Pojďme se krátce podívat, jak funguje GitHub Actions nebo Azure Pipelines jako poskytovatel vývojářské platformy.
Pro GitHub Actions je klíčem k provedení této práce to, že se poskytovatel vývojářské platformy může připojit k zadané instanci GitHubu a pomocí rozhraní REST API Actions aktivovat událost odeslání pracovního postupu k aktivaci spuštění pracovního postupu. Každý pracovní postup může podporovat sadu vstupů přidáním konfigurace workflow_dispatch do souboru YAML 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.
Tyto pracovní postupy nebo kanály nemusí být v úložištích zdrojového kódu aplikace. Konceptem by bylo využít tuto skutečnost k provedení něčeho takového:
- Technici platformy nebo členové týmu DevOps můžou spravovat pracovní postupy nebo kanály v jednom nebo několika centrálních úložištích, ke kterým nemají vývojáři sami přístup, ale poskytovatel vývojářské platformy je nastavený tak, aby používal. Toto stejné úložiště může obsahovat skripty a fragmenty kódu IaC, které používají pracovní postupy nebo kanály.
- Pokud chcete těmto pracovním postupům nebo kanálům umožnit interakci s příslušným podřízeným systémem, provozními operacemi nebo jinými členy vašeho technického týmu platformy, můžou do centrálního úložiště přidat potřebné tajné kódy. Podrobnosti o tom, jak to udělat, najdete v dokumentaci k GitHub Actions a Azure DevOps nebo se můžete rozhodnout centralizovat tajné kódy pomocí služby Azure Key Vault.
- Tyto pracovní postupy nebo kanály pak můžou sledovat model, ve kterém publikují všechny výsledné entity jako artefakt sestavení a nasazení (dokumentace GitHubu, dokumentace Azure DevOps).
- Během běhu může poskytovatel vývojářské platformy sledovat stav pracovního postupu nebo kanálu a aktualizovat stav životního cyklu v orchestrátoru, dokud se nedokončí. Ke sledování aktualizací můžete například použít webhooky s GitHub Actions a hooky služeb s Azure Pipelines .
- Po dokončení může poskytovatel podle potřeby využívat publikovaný artefakt pro zahrnutí do grafu platformy pro vývojáře.
Nakonec můžete tohoto zprostředkovatele vývojářské platformy nastavit tak, aby vystavil sadu šablon do grafu platformy pro vývojáře, který odkazuje na příslušné úložiště a pracovní postup nebo kanál spolu se vstupy pro danou úlohu.
Skvělou věcí při používání systému CI/CD je, že jsou často nastavené tak, aby podporovaly spouštění libovolných rozhraní CLI, takže nepotřebujete prvotřídní, jedinečnou integraci pro všechno, co děláte. Podle potřeby je můžete přidat v průběhu času.
Většina toho, co je popsáno v tomto příkladu, používá způsob fungování jiných typů poskytovatelů. Je také důležité si uvědomit, že použití GitHub Actions nebo Azure Pipelines v tomto kontextu nevyžaduje, abyste je také použili pro vlastní kanály CI/CD.
Další příklady
Tady je několik příkladů jiných typů poskytovatelů vývojářských platforem, kteří můžou zpracovávat šablony.
| Příklad | Popis |
|---|---|
| Operace správy zdrojového kódu | V některých případech může být potřeba vytvořit nebo aktualizovat úložiště, odeslat žádost o přijetí změn nebo provést jinou operaci související se správou zdrojového kódu. I když obecné asynchronní moduly pracovních postupů můžou tyto druhy operací spravovat, může být užitečné provádět základní operace Gitu bez nich. |
| Zřizovací servery infrastruktury | I když GitHub Actions a Azure Pipelines dobře fungují při správě zřizování infrastruktury, můžete se rozhodnout také pro více přímých integrací. Vyhrazený poskytovatel může zjednodušit nastavení a vyhnout se režii. Služby, jako jsou prostředí nasazení Azure nebo Terraform Cloud , se přímo zaměřují na povolení zřizování založeného na šablonách IaC a bezpečné a bezpečné zřizování. Mezi další příklady patří například vytváření oborů názvů Kubernetes pro aplikace ve sdílených clusterech nebo použití gitu s pracovními postupy GitOps pomocí fluxu nebo Argo CD jako konkrétního typu poskytovatele. Dokonce i další modely zaměřené na aplikace, jako je experimentální projekt inkutování operačního systému Radius s vlastními rozhraními CLI, můžou mít v průběhu času vlastní poskytovatele vývojářských platforem. Klíčovou věcí je hledat a plánovat rozšiřitelnost, abyste se mohli přizpůsobit. |
| Generování uživatelského rozhraní aplikace / počáteční | Šablony aplikací jsou důležitou součástí toho, kde v průběhu času vede inženýrská platforma. Modul šablon můžete podporovat tím, že poskytnete vyhrazeného poskytovatele vývojářské platformy, který je navržený nejen pro generování zdrojového stromu aplikace, ale také vytvoření a nasdílení obsahu do úložiště zdrojového kódu a přidání výsledných entit do grafu. Každý ekosystém má vlastní předvolbu generování uživatelského rozhraní aplikace, ať už Yeoman, cookiecutter nebo něco jako Azure Developer CLI, takže model poskytovatele zde umožňuje podporovat více než jedno ze stejných rozhraní. Tady je opět rozšiřitelnost, která je klíčem. |
| Ruční procesy | Bez ohledu na to, jestli se automaticky generuje žádost o přijetí změn pro ruční schválení nebo ruční postup pro osoby, které nejsou vývojáři, aby reagovaly na použití něčeho, jako je Power Platform, je možné použít stejný model založený na šablonách u poskytovatele vývojářské platformy. V průběhu času můžete dokonce přejít na automatizovanější kroky. |
I když možná nebudete potřebovat, aby všichni tito poskytovatelé začali, můžete zjistit, jak rozšíření prostřednictvím něčeho, jako je poskytovatel vývojářské platformy, může pomoct růst schopností automatizace v průběhu času.
Uživatelé a týmy
Příprava platforem je ze své podstaty multisystémová záležitost, takže je důležité naplánovat, jak by samoobslužné základy měly řešit náročnější problémy s integrací těchto systémů dohromady. Tady je strategie pro řešení běžných problémů s identitou, uživateli a týmy.
| Doporučení | Popis |
|---|---|
| Integrace rozhraní API vývojářské platformy přímo se zprostředkovatelem identity pro zajištění optimálního zabezpečení | Pokud chcete zabezpečit rozhraní API platformy pro vývojáře, doporučujeme přímou integraci se zprostředkovatelem identity, jako je ID Microsoft Entra, vzhledem k robustní identitě a možnostem řízení přístupu na základě role (RBAC) pro Entra ID. Existuje mnoho výhod pro přímé použití nativních sad SDK a rozhraní API zprostředkovatele identity (například prostřednictvím ID MSAL Entra) místo abstrakce. Můžete řídit komplexní zabezpečení a spoléhat se na stejný model RBAC během celého procesu a současně zajistit průběžné vyhodnocování zásad podmíněného přístupu (na rozdíl od okamžiku přihlášení). |
| Použití integrace skupin zprostředkovatelů identit a jednotného přihlašování v podřízených systémech | Integrace jednotného přihlašování (SSO) by měly používat stejného zprostředkovatele identity a tenanta, kterého používáte pro rozhraní API platformy pro vývojáře. Nezapomeňte také využít podporu protokolů, jako je SCIM , k připojení ve skupinách zprostředkovatelů identit (jako jsou skupiny AD). Propojení těchto skupin zprostředkovatelů identity do podřízených systémových oprávnění není vždy automatické, ale minimálně můžete ručně přidružit identifikaci skupin zprostředkovatelů k konceptům seskupení jednotlivých nástrojů, aniž byste potom museli ručně spravovat členství. Můžete například zkombinovat podporu Enterprise Managed User (EMU) GitHubu a ručně využít možnost spojit skupiny zprostředkovatelů identit s týmy GitHubu. Azure DevOps má podobné funkce. |
Vytvoření konceptu týmu nad rámec jedné skupiny zprostředkovatelů identity
S tím, jak vaše cesta k vytváření platformy pokračuje, pravděpodobně zjistíte, že skupiny zprostředkovatelů identit jsou skvělé pro správu členství, ale že více skupin se skutečně musí spojit, aby vytvořilo koncept týmu pro řízení přístupu na základě role (RBAC) a agregaci dat.
V kontextu přípravy platforem definujeme tým jako sadu lidí v různých rolích, které spolupracují. Pro agregaci dat je myšlenka týmu s více rolemi důležitá pro výkon zjišťování a zavádění informací na místech, jako jsou řídicí panely pro vytváření sestav. Na druhou stranu je skupina obecným konceptem zprostředkovatele identity pro sadu uživatelů a je navržená s myšlenkou přidání více lidí do konkrétní role, nikoli naopak. S RBAC proto tým může souviset s několika skupinami zprostředkovatelů identit prostřednictvím různých rolí.
Zdroj týmových dat může pocházet z několika různých míst. Pokud například používáte týmy jako vzor kódu (TaC), může poskytovatel vývojářské platformy sledovat změny souborů v úložišti a ukládat je do mezipaměti v profilu uživatele a úložišti týmových metadat. Nebo můžete přímo integrovat něco jako projekt Azure Dev Center, který už má tyto základní konstrukce RBAC k dispozici.
Vytvoření modelu pro integraci s podřízenými systémy na úrovni týmu nebo uživatele
Zatímco některé vývojářské a provozní nástroje a služby budou nativně integrovat a používat koncepty zprostředkovatele identity přímo, mnoho z nich to abstrahuje do vlastní reprezentace skupiny nebo uživatele (i s jednotným přihlašováním). Kromě povolení přístupu napříč nástroji může tato realita také představovat problémy s agregací dat. Konkrétně můžete zjistit, že rozhraní API v podřízené soustavě používají vlastní identifikátory místo identifikátorů zprostředkovatele identity (například ID objektu v Id Entra se nepoužívá přímo). To znesnadňuje filtrování a přidružení dat na úrovni uživatelů nebo týmů, pokud není možné mapovat mezi různými ID.
Řešení rozdílů na úrovni týmu a skupin
Vzory, jako je TaC , umožňují ukládat vztahy mezi týmem nebo identifikátory skupin jednotlivých systémů a přistupovat k nim, abyste mezi nimi mohli namapovat. K rekapitulace zabezpečeného a auditovatelného úložiště Git se stane zdrojem týmu a žádosti o přijetí změn poskytují řízené uživatelské rozhraní pro provádění aktualizací. Systémy CI/CD pak můžou aktualizovat podřízené systémy a zachovat související vztahy identifikátorů pro tým, který k tomu použil.
To například umožňuje ukládání následujících relací ve voláních rozhraní API:
Pokud byste raději používali jiný zdroj dat než soubory v úložišti, můžete stejný obecný koncept použít pomocí orchestrátoru vývojářské platformy k dosažení stejného výsledku. V rámci tohoto modelu může poskytovatel vývojářské platformy pro zdroj týmových dat aktivovat událost aktualizace týmu, kterou všichni ostatní poskytovatelé přijímají a fungují podle potřeby.
Řešení problémů s ID uživatele
Další související výzvou pro přístup k datům a agregací jsou rozdíly v ID uživatele. Podobně jako v případě týmu nemůžete předpokládat, že nativní ID zprostředkovatelů identity (například ID objektu pro Id Entra) podporuje dané rozhraní API, pokud používáte integraci systému do systému k dotazování na uživatele. Tady znovu uložíte mapování id uživatele, které přistupuje k datům prostřednictvím rozhraní API platformy pro vývojáře, může pomoct. Představte si například GitHub:
Pokud můžete pro každý systém vyhledat ID uživatele jiný systém prostřednictvím rozhraní API bez tokenu uživatele, může daný poskytovatel vývojářské platformy toto mapování vygenerovat průběžně. V některých případech to může být složité, protože možná budete muset tuto operaci provést hromadně a uložit výsledky do mezipaměti, aby se zachoval výkon.
Vraťte se zpět s použitím více tokenů uživatele.
V situacích, kdy poskytovatelé potřebují získat přístup k datům na úrovni uživatele bez způsobu, jak provádět překlad ID uživatele, který by fungoval, je možné nastavit rozhraní API platformy pro vývojáře tak, aby spravovalo více tokenů uživatelů. Příklad:
- Rozhraní API platformy pro vývojáře může podporovat mezipaměť uživatelských tokenů specifických pro poskytovatele pro použití s podřízenými systémy.
- Všechny interakce s daným poskytovatelem aktivovaným rozhraním API by zahrnovaly token uživatele poskytovatele, pokud je k dispozici.
- Pro zpracování případu, kdy nebyl k dispozici žádný token uživatele, by poskytovatel aktivoval tok OAuth, aby ho získal.
- Abychom mohli začít, rozhraní API platformy pro vývojáře by předalo identifikátor URI ověřování pro tok OAuth s identifikátorem URI přesměrování, který byl předán poskytovateli. Předaný identifikátor URI by zahrnoval kód nonce / jednorázové použití.
- Rozhraní API pak vrátí odpověď neověřenou pomocí identifikátoru URI.
- Jakýkoli UX pak může pomocí tohoto identifikátoru URI řídit příslušný tok ověřování v prohlížeči.
- Jakmile dojde k přesměrování, vývojářská platforma obdrží potřebný token uživatele a uloží ho do mezipaměti pro budoucí referenci spolu s ID uživatele.
- Klient pak může zkusit znovu volání rozhraní API, což by pak proběhlo úspěšně.
Tento koncept popisuje způsob, jak řešit složité ověřování, protože id můžete opakovaně používat, pokud je to možné, a nemusíte udržovat samostatné identifikátory URI přesměrování na podřízený systém.
Použití přímých odkazů na kontextové odkazy na nástroje a systémy generování sestav
Až do této chvíle jsme mluvili o aspektu automatizace problémového prostoru. Tento postup může trvat dlouho, protože uživatelské rozhraní může používat hodnoty v entitách vrácených během automatizace k vytvoření přímých odkazů do jiných systémů pro tým.
I když to nesouvisí s automatizací, můžou poskytovatelé vývojářských platforem generovat jakýkoli druh potřeb entit. Obecně ale nechcete do grafu vývojářské platformy přenést všechna podrobná data napříč celou interní vývojářskou platformou. Řídicí panely v řešení pozorovatelnosti, jako je Grafana, Prometheus, DataDog nebo analýza kódu v produktech, jako je SonarQube, a nativní funkce v sadách DevOps, jako je GitHub a Azure DevOps, jsou velmi schopné. Nejlepší přístup je místo toho často vytvářet přímé odkazy na tyto další systémy. Vaše entity můžou poskytnout dostatek informací k vytvoření odkazů, aniž by přímo obsahovaly podrobné informace, jako je obsah protokolu.
V případech, kdy chcete agregovat a sumarizovat data napříč nástroji nebo potřebujete řídit vlastní metriky, můžou být řešení pro vytváření sestav Power BI nebo Microsoft Fabric vaším dalším portem volání. Pokud chcete sloučit týmová data, můžete se buď připojit k databázi nadace, nebo si projít rozhraní API platformy pro vývojáře. Například, jak je popsáno v části Plánování a stanovení priority, je jedno místo, kde můžete chtít, aby vlastní řídicí panel měří úspěch vaší interní vývojářské platformy.
Vybírejte se s každým dalším prostředím, které sestavíte
I když může být zajímavé znovu vytvářet stávající funkce v něčem, jako je běžný portál, mějte na paměti, že ho budete také muset udržovat. To je oblast, ve které je důležité sledovat myšlení produktu. Rozhraní stylu řídicího panelu jsou snadno pochopitelná a srozumitelná, ale vývojáři můžou najít další hodnotu jinde.
To znamená, že model zde umožňuje používat agregovaná data v grafu vývojářské platformy k vytváření vlastních uživatelských prostředí. Entity by měly mít integrovanou podporu, aby se mohly spojit s uživatelem nebo týmem. To umožňuje rozhraní API platformy pro vývojáře nastavit rozsah výstupu (společně s indexováním a ukládáním do mezipaměti).
I když ale potřebujete místo hloubkového propojení vytvořit vlastní uživatelské prostředí, není nejlepší přístup k načtení všech dat do grafu vývojářské platformy. Představte si například situaci, kdy můžete chtít zobrazit protokoly v uživatelském prostředí, které už mají dobře definovanou a spravovanou domovskou stránku. Informace v souvisejících entitách vám pomůžou shromažďovat informace přímo z podřízených systémů.
Abyste mohli začít, možná budete muset použít integraci systému do systému pro připojení, ale jakmile implementujete některý z modelů popsaných v uživatelích a týmech, můžete v případě potřeby použít jakékoli uložené ID podřízeného uživatele nebo týmové ID nebo ověřovací tokeny uživatele.
Tady je několik příkladů běžných prostředí, která je potřeba vzít v úvahu:
| Příklad | Popis |
|---|---|
| Objevování a průzkum | Jako jeden inženýr platformy to uvedl: "Co zpomaluje projekty je komunikace, ne vývojářské dovednosti." – Daniel, Cloud Engineer, Fortune 500 Media Company. Vzhledem k tomu, že software je týmový sport, vytvoření uživatelského rozhraní, které pomáhá objevovat týmy, a entity, které vlastní, jsou obvykle jednou z prvních věcí, které je potřeba řešit. Hledání, zjišťování a dokumentace napříč týmy pomáhají podporovat opakované použití a spolupráci pro vnitřní zdroje nebo podporu. Týmy také můžou využívat jeden stop shop a najít věci, které vlastní, včetně prostředí, úložišť a dalších prostředků, jako jsou dokumenty. |
| Ruční registrace prostředí nebo prostředků | I když je možné prostřednictvím orchestrátoru vývojářské platformy zřídit a sledovat mnoho věcí, můžete také chtít zaregistrovat prostředky nebo prostředí, která už existují nebo ještě nejsou automatizovaná. Tady může být užitečný jednoduchý poskytovatel, který přebírá informace z úložiště Git a přidává informace do prostředků nebo správy prostředí. Pokud už máte katalog softwaru, stane se to také způsobem, jak ho integrovat do modelu. |
| Katalog rozhraní API | Sledování rozhraní API, která by měli vývojáři používat, může trvat dlouho. Pokud ještě něco nemáte, můžete dokonce začít s jednoduchým úložištěm Gitu s řadou souborů představujících rozhraní API, jejich stav a pomocí žádostí o přijetí změn můžete spravovat pracovní postup schválení. Můžete je přidat do grafu platformy pro vývojáře, aby je bylo možné zobrazit nebo přidružit k jiným entitám. Pro robustnější funkce můžete integrovat něco jako Centrum rozhraní API Microsoftu nebo jiný produkt. |
| Dodržování licence | V některých případech můžete také chtít získat přehled o dodržování předpisů a spotřebě licencí softwaru. Vývojářské platformy můžou také přidávat automatizaci potřebnou k využívání licencí, ale i když jsou licence přiřazené ručně (například prostřednictvím procesu žádosti o přijetí změn v úložišti Git), vývojář vidí, co mají (a schopnost správce zobrazit všechno). |
| Zobrazení Kubernetes zaměřené na aplikaci | Když používáte sdílený cluster Kubernetes, může být pro vývojáře obtížné najít a pochopit stav jejich aplikací prostřednictvím uživatelského prostředí správce clusteru. Různé organizace se můžou rozhodnout tento problém vyřešit jinak, ale použití oboru názvů k reprezentaci aplikace je jedním z dobře známých způsobů, jak to udělat. Odtud můžete pomocí entit vytvořit přidružení mezi oborem názvů aplikace v clusteru a týmem a vytvořit více vývojářský pohled na stav aplikace a poskytnout přímé odkazy na jiné nástroje nebo webové uživatelské rozhraní. |
Uživatelské prostředí
Různé role ve vaší organizaci mají nástroje nebo služby, které představují střed závažnosti pro každodenní práci. Síla těchto systémů může ztížit nové uživatelské prostředí mimo tato centra závažnosti, aby získala trakci. V dokonalém světě můžou vývojáři, provoz a další role dál pracovat v prostředí, které jim dává smysl – často ty, které už používají.
S ohledem na to je vhodné při plánování více uživatelských rozhraní při pokroku na cestě přípravy platformy. To může také poskytnout příležitost začít jednoduchou, prokázat hodnotu a růst směrem ke složitějším rozhraním, jak vzniká potřeba.
Integrace toho, co máte
Pokud jste si přečetli články o použití softwarových inženýrských systémů a upřesňování aplikační platformy , pravděpodobně jste identifikovali systémy, které chcete dál používat. V obou případech vyhodnoťte, jestli můžete vylepšit a rozšířit to, co máte, než začnete vytvářet nová prostředí od začátku. (Zeptejte se sami sebe, budou lidé lépe reagovat na jiné nové uživatelské prostředí nebo vylepšenou verzi něčeho, co teď mají?)
Některé z nástrojů, nástrojů nebo webových aplikací, které chcete dál používat, budou vlastní a jsou vhodnými kandidáty na vylepšení. Nezapomeňte ale věnovat pozornost tomu, jestli vaše oblíbené nástroje a služby mají model rozšiřitelnosti, který můžete použít. Získáte spoustu výhod od začátku. To může eliminovat bolesti hlavy v oblasti údržby a zabezpečení a umožní vám zaměřit se na problém, který se pokoušíte vyřešit.
Můžete například rozšířit následující plochy, které už používáte:
- Editory a prostředí IDE.
- Vaše sada DevOps.
- Rozhraní CLI jsou také stále rozšiřitelnější.
- Prostředí s nízkými nebo bez kódu, jako je Power Pages.
Každý z nich může poskytnout lepší výchozí bod pro danou roli než něco, co jste nastavili úplně od začátku, protože jsou stávajícím centrem závažnosti. Běžné rozhraní API platformy pro vývojáře jako směrný plán vám umožní prohodit věci, experimentovat a měnit v průběhu času.
Zvažte rozšíření webového editoru pro vytvoření portálu pro vývojáře.
Pokud hledáte webové prostředí pro vývojáře, mějte na paměti, že nedávný trend je webové verze editorů a vývojových prostředí. Mnoho z nich, jako jsou ty, které používají VS Code, mají podporu rozšíření. V nástroji VS Code se všechno, co vytváříte pro tato webová prostředí, pak přeloží místně za dvojitou výhodu.
Kromě služeb, jako je GitHub Codespaces, vscode.dev je bezplatná webová verze editoru VS Code bez výpočetních prostředků, ale zahrnuje podporu pro určité typy rozšíření, včetně těch, které používají webviews pro vlastní uživatelské rozhraní.
I když vaši vývojáři nepoužívají VS Code samotný, vzory uživatelského rozhraní jsou dobře známé a najdete je v jiných vývojářských nástrojích. Použití vscode.dev může kromě samotného nástroje poskytnout pohodlný a známý webový základ pro vývojářské prostředí.
Můžou fungovat jako portál zaměřený na vývojáře ve známém formuláři, který se dá přeložit i na místní použití.
ChatOps
Další příležitostí, která je často přehlédnuta, je implementace rozhraní ChatOps. Vzhledem k nárůstu chatovacích rozhraní kvůli nárůstu produktů umělé inteligence, jako je ChatGPT a GitHub Copilot, můžou příkazy akcí nebo příkazy lomítka poskytnout užitečný způsob, jak aktivovat pracovní postupy automatizace, zkontrolovat stav a další. Vzhledem k tomu, že většina platforem CI/CD aplikací má předem připravenou podporu pro systémy, jako jsou Microsoft Teams, Slack nebo Discord, může být přirozeným způsobem integrace s dalšími vývojáři uživatelského rozhraní a souvisejícími provozními rolemi, které každý den používají. Kromě toho všechny tyto produkty mají model rozšiřitelnosti.
Investice do nového portálu pro vývojáře
Pokud nemáte existující portál nebo rozhraní, které chcete použít jako základ, můžete se rozhodnout vytvořit nový vývojářský portál. Představte si to jako cíl, nikoli jako výchozí bod. Pokud ještě nemáte vývojový tým, který s vámi spolupracuje, je čas začít s tímto úsilím. Každá organizace je jiná, takže neexistuje žádná odpověď, která by měla být v tomto druhu prostředí. V důsledku toho neexistuje žádná defacto odpověď na předbalený produkt, který můžete aktivovat a použít tak, jak je to dnes.
U vlastních možností místního hostování nejsou obecné architektury webového portálu nové a vaše vývojové týmy už můžou používat ty, ke které byste mohli klepnout. Pokud se snažíte dostat něco před uživatele, abyste získali časnou zpětnou vazbu, můžete dokonce začít s něčím tak jednoduchým, jako je power pages s nízkým kódem, abyste se mohli připojit k rozhraní API pro běžnou platformu pro vývojáře.
Novější úsilí o portál pro vývojáře je názornější. Například Backstage.io je vlastní sada nástrojů portálu pro vývojáře, která byla původně vytvořená tak, aby vyhovovala potřebám Spotify. Obsahuje rozhraní příkazového řádku, které vám pomůže spustit zdrojový strom podobně jako create-react-app pro React.js.
Jako sada nástrojů portálu vyžaduje, aby se práce zpracovala a při přizpůsobení vyžadovala znalost TypeScriptu, Node.js a Reactu. Skvělá věc o tom ale je, že jako sada nástrojů můžete téměř cokoli změnit. Má také vlastní katalog softwaru a mechanismus šablonování, ale jejich použití není vyžadováno a má dobře definovaný způsob, jak přinést nový 1st a 3rd party kód označovaný jako pluginy.