Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az önkiszolgálás védőkorlátokkal ellátva az az alapelv, amelynek célja, hogy a fejlesztői csapatok saját döntéseket hozhassanak egy jól meghatározott paramétereken vagy védőkorlátokon belül. A védőkorlátokat a főbb érdekelt felek hozták létre és fogadták el. Az érdekelt felek a szervezet biztonsági, üzemeltetési és architektúracsapatai is lehetnek.
Az önkiszolgáló megoldások használatával, amelyekhez védőkorlátok tartoznak, a fejlesztőcsapatok megőrzik az önállóságukat, hogy függetlenül hozhassanak fejlesztési döntéseket. Az automatizálás és a szabályzat segít az érdekelt feleknek biztosítani a biztonság, a megfelelőség, a műveletek, a szabványok és a költségek megfelelő kezelését. Az automatizálás engedélyezéséhez a csapatvonalak közötti együttműködésre van szükség, hogy a fejlesztők, az operátorok és a szakemberek többet tudjanak tenni a szükséges irányítás feláldozása nélkül. A fejlesztők ezután a lehető leggyorsabban az üzleti érték átadására összpontosíthatnak.
[Elmondjuk a fejlesztőknek,] ne aggódjanak azzal kapcsolatban, hogy hogyan működik, csak kapcsolják be vagy ki, töltsenek ki, illesszék be a szükséges szöveget, lényegében ez egy önkiszolgáló rendszer, ahol van egy README fájl, és rendelkeznek bemenetekkel, kimenetekkel, és bármit beilleszthetnek, amit csak szeretnének. - Daniel, felhőmérnök, Fortune 500 médiavállalat
A burkolt útvonalak önkiszolgáló élményének biztosításának célja a fejlesztői munka csökkentése, valamint a fejlesztői csapatok, a műveletek és a menedzsment számára a láthatóság biztosítása. Az ötlet az, hogy olyan élményt hozzon létre egy adott feladathoz, amely minimális tanulási görbével rendelkezik, részben az alapul szolgáló automatizálási és adatösszesítési képességeknek köszönhetően. Az olyan tevékenységeken túl, mint az infrastruktúra kiépítése, ezek a szolgáltatások hozzáférést biztosítanak a megfigyelhetőség, a szabályzat, az incidenskezelés és egyebek kritikus képességeihez. Az ötlet kiterjed a belső API-k, SDK-k, valamint megosztott eszközök és szolgáltatások felderítésére és megosztására. Ezek a szolgáltatások csökkentik a többletterhelést, így a fejlesztői csapatok a teendők elvégzésére összpontosíthatnak.
A belső fejlesztői platformok lehetővé teszik a fejlesztők számára, hogy digitális áruházi ügyfelekként működjenek
A belső fejlesztői platformok olyan képességeket biztosítanak, amelyek hasonlóak az üzletközi digitális áruházakhoz. A digitális áruházak eleve úgy vannak kialakítva, hogy segítsék ügyfeleik önkiszolgáló kiszolgálását. Több átviteli sebességet képesek kezelni, mint a hagyományos kirakatokat, mert lehetővé teszik az érdekes elemek felderítését és teljesítését anélkül, hogy bárkivel kellene beszélniük. Ezzel az analógiával a fejlesztők az ügyfelek, és a belső fejlesztői platform hasonló önkiszolgáló élményt nyújt. Az operátorok, a platformmérnökök és más szerepkörök ezután beállítanak egy katalógust azokról az elemekről, amelyeket a fejlesztők kérhetnek, és amelyeket a szervezeti védőkorlátok elhelyezésére terveztek.
Gondolhat például arra, hogy egy fejlesztő hozzáférést kér egy új eszközhöz, mintha digitális áruházbeli megrendelést végeznének. A megrendeléshez hasonlóan a kérés elküldése után a fejlesztő nyomon szeretné követni az előrehaladást, és tudni szeretné, hogy mikor fejeződik be. A háttérben a kérést automatikusan a megfelelő teljesítési szolgáltatóhoz kell irányítani, hogy megfeleljen az igényeknek. A folyamatos integrációs és kézbesítési (CI/CD) rendszerek egyikét tekintheti egy teljesítési szolgáltatónak, egy GitOps-eszközt vagy egy előíró alkalmazásplatformot másodikként, a manuális folyamatok munkafolyamat-automatizálási eszközét pedig harmadikként. A fejlesztő minden esetben ugyanúgy kiszolgálhat elemeket egy jól definiált katalógusból.
Használja az "everything as code" mintát
Az infrastruktúra mint kód (IaC) használata folyamatos telepítési (CD) folyamatokkal és GitOps-eszközökkel az önkiszolgálás engedélyezésének fontos része. A CD-vel rendelkező IaC lehetővé teszi a Bicep-, Terraform-, Helm-diagramok és egyéb eszközök használatát a felhőerőforrások igény szerinti létrehozásához és megsemmisítéséhez. Mivel a felhőinfrastruktúra konfigurációja ugyanúgy kezelhető, mint a forráskódtárban lévő kód, a Git-adattár minden előnyét alkalmazhatja, például a biztonságot és az auditálást.
A közös infrastruktúra és eszközök kiépítése nem az IaC-megközelítés egyetlen előnye. Az IaC-mintát más forgatókönyvekhez is módosíthatja, beleértve a kódként való biztonságot és a szabályzatot kódként (például az Azure Policy és az Open Policy Agent használatával). Ezt a technikát követve a rendszer egy konfigurációs fájlt , általában YAML-t vagy JSON-t küld az adattárba, amely elindít egy munkafolyamatot, amely feldolgozza a fájlt. Ezek a fájlok lehetnek alkalmazástárak, például dependabot.yml vagy CODEOWNERS, vagy egy külön központi adattárban tarthatók fenn. Ezt akár a saját forgatókönyvekre is kiterjesztheti, hogy valóban valósággá tegyen mindent kódként (EaC).
A fejlesztők egy központi katalógussal hivatkozhatnak ezekre a EaC-sablonokra, amelyek önkiszolgáló élményt biztosítanak, és alapértelmezés szerint ajánlott eljárásokat támogatnak.
Megfelelő kezdési sablonok létrehozása és a megfelelő szabályozás kialakítása
A szoftverfejlesztésben az alkalmazások tervezésekor a beágyazást, a modularitást és a kompatibilitást szeretnénk elérni. Ugyanezt a gondolkodásmódot kell alkalmaznia a platformfejlesztésre a templating használatával. Létrehozhat és használhat például központilag biztonságos, újrafelhasználható IaC-sablonokat az infrastruktúra építőelemeiként.
Modulokat hozunk létre a [fejlesztők] számára... így ahelyett, hogy maguknak kellene írniuk vagy aggódniuk bármelyik háttérrendszer miatt, mindössze az alkalmazáskódjuk miatt kell aggódniuk. - Daniel, felhőmérnök, Fortune 500 médiavállalat
Az IaC, az EaC és az alkalmazássablonok kombinálása egy testre szabott, kódként (EaC) nyújtott megoldással, amely más tevékenységekre is kiterjed, például forráskódtár létrehozására, mintakód beírására, vagy konfigurációs és mintakód megadására az ajánlott megfigyelhetőségi eszközökhöz. Ezek az IaC-, EaC- és alkalmazássablonok ezután tárolhatók vagy hivatkozhatók egy központi, biztonságos helyről, például egy adattárból, az Azure Deployment Environments katalógusából vagy a natív felhőhöz készült Azure Container Registryből.
Ha a megfelelő induló sablonok automatikus szabályozással, vizsgálattal és szabályzatkonfigurációval vannak kombinálva, a fejlesztők az első naptól helyes utat követhetik.
A sablonok leegyszerűsítik a fejlesztést automatizált, biztonságos eljárásokkal
Alkalmazássablonok használatával elindíthatja a definiált, burkolt útvonalakat a fejlesztők által a projekt során átváltott kulcsfontosságú döntések és műveletek érdekében. A megfelelő sablonok biztonságos, szabályozott fejlesztési eljárásokat hoznak létre, és lehetővé teszik a fejlesztők számára a gyors kezdést azáltal, hogy lehetővé teszik az automatizálást, amely hozzáférést biztosít a szükséges eszközökhöz, konfigurálja a CI-/CD-folyamatokat, kiépíti az infrastruktúrát és az alkalmazásvermet, valamint konfigurál egy olyan adattárat, amely a szükséges SDK-kat vagy API-kra mutató hivatkozásokat tartalmazó kazánlemez-forráskóddal van kiegészítve.
Ha ezek az alkalmazássablonok más központosított sablonokra (például IaC-sablonokra) hivatkoznak, az egyes építőelemek mindegyike saját kezdősablonokká válik. Ezek a sablonok központi szerepet játszik az önkiszolgáló szolgáltatások engedélyezésében, mivel nem csak kimeneteket határoznak meg, hanem a fejlesztők által választható lehetőségeket is.
A sablonok biztosítják a szabályozást, a biztonságot és a költségoptimalizálást
A sablonoknak azonban nem csupán a fejlesztési erőfeszítések rendszerindítását kell elvégeznie. Emellett létre kell hozniuk az irányítást és irányítást az irányelvekkel és a biztonsági szkenneléssel, amely ahhoz szükséges, hogy a projekt életciklusa alatt megfelelő módon irányítsák a folyamatokat. Egy másik példaként a sablonok olyan ágvédelmi szabályokat állíthatnak be, amelyek megakadályozzák a jogosulatlan egyesítéseket a gyártási környezetbe. Mivel a sablonok az ajánlott eljárásokat és a gyakori konfigurációkat rögzítik, a költségek eszközök, szállítók és csapatok közötti optimalizálásának egyik fő technikája.
A kétirányú kommunikáció kiépítéséhez futtassa a megfelelő kampányokat
Végül, ahogy növekszik a burkolt útvonalak iránti bizalma, használhatja az alkalmazássablonokba összeállított alapvető építőelemeket a meglévő alkalmazások burkolt útvonalra való áthelyezéséhez. Mivel a belső ügyfelek már látják a kipróbált útvonalak értékét, egy belső helyzetfelmérő kampányt futtatva létrehozhat egy kétirányú párbeszédet más alkalmazáscsapatokkal. A fejlesztők megtanulhatják, hogyan migrálhatják az alkalmazásukat, miközben a platformmérnöki csapat egyidejűleg többet is megtudhat arról, hogyan fejlesztheti a platformot számukra.
Saját utazás diagramja
Tekintettel az önkiszolgáló képességek által lefedett élmények széles skálájára, fontos, hogy befektetési erőfeszítéseit erre összpontosítsa, és tervezzen és priorizáljon annak érdekében, hogy belső fejlesztői platformja fokozatos értéket nyújtson. Minden szervezetnek más az útja a belső fejlesztői platform létrehozásában, és a termékszemlérek követése segít az önkiszolgáló élményeket igénylő legkritikusabb helyek megcélzásában.