Szoftvermérnöki rendszerek alkalmazása

A fejlesztői önkiszolgáló fejlesztésnek kell az egyik első problémának lennie a platformfejlesztés során.

Az automatikus önkiszolgáló szolgáltatások engedélyezésének egyik legegyszerűbb módja a meglévő mérnöki rendszerek újrafelhasználása. Ezek a rendszerek nem csak az Ön és a belső ügyfelek számára ismerősek, hanem számos automatizálási forgatókönyvet is lehetővé tehetnek, még akkor is, ha a kezdeti felhasználói élmény nem szép.

Ez a cikk tippeket nyújt a mérnöki rendszerek alkalmazásához az önkiszolgáló forgatókönyvek szélesebb skálájának kezelésére, valamint az ajánlott eljárások sablonba való beágyazásának részleteit, amelyek segítenek a helyes kezdésben és a helyes használatban.

Az alapszintű DevOps- és DevSecOps-eljárások kiértékelése

A mérnöki rendszerek a belső fejlesztői platform kritikus elemei. A DevOps és a DevSecOps fő bérlőiből belső fejlesztői platformok épülnek fel a kognitív terhelés csökkentése érdekében minden érintett számára.

A DevOps a fejlesztést és a műveleteket kombinálva egyesíti az embereket, a folyamatokat és a technológiát az alkalmazástervezés, a fejlesztés, a teljesítés és a műveletek terén. Célja, hogy javítsa az együttműködést olyan történelmileg silózott szerepkörökben, mint a fejlesztés, az informatikai műveletek, a minőségfejlesztés és a biztonság. Folyamatos hurkot hozhat létre a fejlesztés, az üzembe helyezés, a monitorozás, a megfigyelés és a visszajelzés között. A DevSecOps az alkalmazásfejlesztési folyamat során folyamatos biztonsági gyakorlatokat alkalmazva rétegződik ebbe a hurokba.

A következő szakaszok a platformmérnöki mozgáshoz közvetlenül kapcsolódó fejlesztésekre összpontosítanak: a burkolt útvonalak, az automatizált infrastruktúra kiépítése (az alkalmazás üzembe helyezése mellett), a kódolási környezet beállítása, valamint az önkiszolgáló kiépítés és az eszközök, csapateszközök és szolgáltatások konfigurálása, amelyek nem részei közvetlenül az alkalmazásfejlesztési ciklusnak.

A kívánt burkolt útvonalak létrehozása

Ha már több olyan eszközkészlettel rendelkezik, amelyek a mérnöki rendszereket alkotják, az egyik korai döntés az, hogy össze szeretné-e egyesíteni őket a kezdeti platformmérnöki erőfeszítések részeként, vagy a kezdetektől fogva támogatja a különböző eszközök konstellációját. Az eszközök ezen konstellációjának burkolt útvonalkészletének meghatározása a leghatékonyabb, és nagyobb rugalmasságot biztosít.

Amikor áttér a termék-központú gondolkodásra, tekintse a mérnöki rendszereket ezekben a már kitaposott ösvényekben központilag kezelt eszközök összességének, amelyeket a fejlesztői csapatok szolgáltatásaként biztosítanak. A szervezeten belüli egyes csapatok vagy részlegek eltérhetnek egymástól, de várhatóan külön kezelik, karbantartják és fizetik az eszközeiket, miközben továbbra is betartják a megfelelőségi követelményeket. Ez lehetővé teszi új eszközök betáplálását az ökoszisztémába megszakítás nélkül, mivel kiértékelhet mindent, ami eltér a burkolt útvonalba való esetleges belefoglalástól az idő múlásával. Ahogy egy platformmérnöki vezető fogalmazott:

Még mindig megteheti a saját dolgát, de abba az irányba, amerre mi megyünk. bármit megváltoztathat, de ez az Ön felelőssége lesz. Öné a változások - Öné az éles kések. - Mark, platformmérnöki vezető, nagy európai multinacionális kiskereskedelmi vállalat

Mivel a platformfejlesztés egyik fő célja, hogy olyan termékszemlére váltson, amelyben értéket biztosít a belső ügyfeleknek, ez a csillagképi megközelítés általában jobban működik, mint egy felülről lefelé irányuló megbízás. A burkolt útvonalak kialakítása és finomítása során némi rugalmasságot hagyva lehetővé teszi a csapatok számára, hogy bemenetet adjanak és kezeljenek egy adott alkalmazás minden igazán egyedi követelményét anélkül, hogy a szervezet más tagjait érintenék. Ez teljesen burkolt, aranyozott utakhoz vezet, míg mások csak részben kövezettek. Azokban az esetekben, amikor nincsenek egyedi követelmények, a csapatok által végzett extra munkafejlesztés természetesen azt eredményezi, hogy idővel egy támogatott útvonalra szeretnének lépni.

Ha inkább konszolidálási stratégiát szeretne, a meglévő alkalmazások migrálása a vártnál több munkát jelenthet, ezért az első lépésekhez valószínűleg a terület kezdési szempontjára kell összpontosítania, és az új projektekre kell összpontosítania. Ez biztosítja az első burkolt utat, míg minden más eleve burkolatlan. A nem előkészített útvonal fejlesztői csapatai ezután fontolóra vehetik az áthelyezést, miután az új burkolt útvonal megjeleníti annak értékét a szervezet számára. Ezen a ponton indíthat egy egységesítési kampányt, hogy mindenki elérje a kívánt állapotot kétirányú kommunikáció révén, mivel a fejlesztői csapatok ezt inkább előnynek tekintik, mint adónak. A kampány során a platformmérnöki csapatok a csapatok migrálásának segítésére összpontosíthatnak, míg a fejlesztői csapatok visszajelzést adnak arról, hogyan teheti jobbá a kikövezett útvonalakat.

Ettől függetlenül ne kötelezze a burkolt útvonalak használatát. A burkolt útvonalak bevezetésének leghatékonyabb módja az, ha kihangsúlyozza, hogy a csapatok mit kapnak ki belőlük a kényszerű bevezetés helyett. Mivel a belső fejlesztői platform arra összpontosít, hogy ezeknek a csapatoknak a megelégedettségét szolgálja, a költségvetési és idő–érték arányú nyomás az egyes vezetőkre hárul, ami intézi a többieket. Szerezze meg a megfelelő kampányokat, majd teremtsen lehetőséget a kétirányú kommunikációhoz, a legjobb módon azoknak, akik egy burkolatlan úton szeretnének átváltani.

Fejlesztői automatizálási eszközök használata a burkolt útvonalak önkiszolgálóbbá tételéhez

Az első burkolt útvonal létrehozásának része az alapvető fejlesztői automatizálási termékek létrehozása. Ezek fontosak, amikor elkezd gondolkodni a fejlesztői önkiszolgáló képességek engedélyezéséről.

Automatikus alkalmazásinfrastruktúra kiépítésének engedélyezése a folyamatos teljesítés során

Ha még nem implementálták, a tervezés során azonosított problémák valószínűleg olyan problémákra mutatnak, amelyek megoldásában segíthet a folyamatos integráció (CI) és a folyamatos teljesítés (CD). Ezen a területen olyan termékek találhatók, mint a GitHub Actions, az Azure DevOps, a Jenkins, valamint a lekéréses gitOps-megoldások, például a Flux vagy az Argo CD . Ezeket a témaköröket a Microsoft DevOps erőforrásközpontban kezdheti el.

Még ha már implementált egy módszert az alkalmazás folyamatos üzembe helyezésére a meglévő infrastruktúrában, érdemes megfontolnia az infrastruktúra kódként (IaC) való használatát a szükséges alkalmazásinfrastruktúra cd-folyamat részeként történő létrehozásához vagy frissítéséhez.

Vegyük például az alábbi ábrákat, amelyek két módszert mutatnak be, amelyek a GitHub Actions használatával frissítik az infrastruktúrát, és üzembe helyezik őket az Azure Kubernetes Service-ben: egy leküldéses alapú üzembe helyezést és egy lekéréses alapú (GitOps) üzembe helyezést.

A kiválasztott célalkalmazási platformot a meglévő IaC-képességkészlet és a célalkalmazási platform részletei vezérlik. A GitOps-megközelítés a legújabb, és népszerű a kubernetes-t használó szervezetek körében az alkalmazásaik alapjaként, míg a lekéréses alapú modell jelenleg a lehető legnagyobb rugalmasságot biztosítja a rendelkezésre álló lehetőségek száma alapján. Azt várjuk, hogy a legtöbb szervezet a kettő kombinációját használja. Ettől függetlenül az IaC-eljárásokban való jártosság segíthet a további automatizálási forgatókönyvekre vonatkozó minták elsajátításában.

Az IaC központosítása katalógusban vagy beállításjegyzékben a biztonság skálázása és javítása érdekében

Az IaC alkalmazások közötti kezeléséhez és skálázásához központilag közzé kell tennie az IaC-összetevőket az újrafelhasználáshoz. Használhat például Terraform-modulokat egy beállításjegyzékben, Bicep-modulokban, Radius-receptekben vagy Helm-diagramokban , amelyeket egy natív felhőbeli OCI Artifact-beállításjegyzékben tárol, például az Azure Container Registryben (ACR),a DockerHubban vagy az Azure Deployment Environments ( ADE) katalógusában. A GitOps és a Kubernetes esetében a Fürt API (és az olyan implementációk, mint a CAPZ) lehetővé teszik a Kubernetes számítási feladatfürtjeinek kezelését, míg az egyéni erőforrásdefiníciók, például az Azure Service Operator további támogatást biztosíthatnak más típusú Azure-erőforrásokhoz. Más eszközök, például a Crossplane több felhőben is támogatják az erőforrásokat. Ezek lehetővé teszik, hogy központosított vagy közös Helm-diagramokat használjon az ACR-hez hasonló módon a forgatókönyvek szélesebb skálája érdekében.

Az IaC központosítása javítja a biztonságot azáltal, hogy jobban szabályozhatja, hogy kik végezhetnek frissítéseket, mivel azok már nem alkalmazáskóddal vannak tárolva. A kódfrissítés során bekövetkező véletlen változás kisebb kockázattal jár, ha a szakértők, a műveletek vagy a platformmérnökök elvégezik a szükséges módosításokat. A fejlesztők is élvezhetik ezeket az építőelemeket, mivel nem kell teljes IaC-sablonokat létrehozniuk, és automatikusan kihasználhatják a kódolt ajánlott eljárásokat.

A választott IaC-formátum a meglévő képességkészlettől, a szükséges vezérlési szinttől és a használt alkalmazásmodelltől függ. Az Azure Container Apps (ACA) és a nemrégiben kísérleti Radius OSS-inkubációs projekt például előre meghatározottabb irányelveket tartalmaznak, mint a Kubernetes közvetlen használata, de a fejlesztői élményt is egyszerűbbé teszik. A különböző modellek előnyeiről és hátrányairól a felhőszolgáltatás-típusok leírásában olvashat. Ettől függetlenül a központosított és felügyelt IaC-ra való hivatkozás ahelyett, hogy teljes definíciókat tartalmaz a forrásfában, jelentős előnyökkel jár.

A szükséges kiépítési identitások vagy titkos kódok megőrzése oly módon, hogy a fejlesztők közvetlenül ne férhessenek hozzá a rétegekhez az alapvető szabályozási építőelemekben. Vegyük például ezt az ábrát az Azure Deployment Environments (ADE) használatával elérhető szerepkör-elkülönítésről.

Itt a platformmérnökök és más szakemberek fejlesztik az IaC-t és más sablonokat, és elhelyezik őket egy katalógusban. A műveletek ezután környezeti típus szerint adhatnak hozzá felügyelt identitásokat és előfizetéseket, és hozzárendelhetnek fejlesztőket és más felhasználókat, akik használhatják őket a kiépítéshez.

A fejlesztők vagy a CI/CD-folyamat ezután az Azure CLI vagy az Azure Developer CLI használatával előre konfigurált és szabályozott infrastruktúrát építhetnek ki anélkül, hogy hozzá kellene férniük az ehhez szükséges mögöttes előfizetéshez vagy identitásokhoz. Akár az ADE-hez hasonlót használ, akár nem, a választott folyamatos kézbesítési rendszer segíthet az infrastruktúra biztonságos és biztonságos frissítésében azáltal, hogy titkos kulcsokat választ el, és az IaC-tartalmakat olyan helyektől választja el, amelyekhez a fejlesztők önmagukban nem férhetnek hozzá vagy módosíthatnak.

Önkiszolgáló szolgáltatás engedélyezése az alkalmazások folyamatos kézbesítését meghaladó helyzetekben

Bár a CI- és CD-fogalmak az alkalmazásfejlesztéshez kötődnek, a belső ügyfelek által kiépíteni kívánt elemek közül sok nem kapcsolódik közvetlenül egy adott alkalmazáshoz. Ez lehet megosztott infrastruktúra, adattár létrehozása, kiépítési eszközök stb.

Ha szeretné megtudni, hogy ez hol segíthet, gondolja át, hogy jelenleg hol vannak manuális vagy service-desk-alapú folyamatai. Mindegyiknél gondolja át ezeket a kérdéseket:

• Milyen gyakran történik ez a folyamat?
• Lassú, hibára hajlamos a folyamat, vagy jelentős munkát igényel?
• Ezek a folyamatok manuálisak a szükséges jóváhagyási lépés vagy egyszerűen az automatizálás hiánya miatt?
• Ismerik a jóváhagyók a forrásvezérlő rendszereket és a lekéréses kérelmek folyamatát?
• Milyen naplózási követelmények vonatkoznak a folyamatokra? Ezek eltérnek a forrásvezérlő rendszer naplózási követelményeitől?
• Vannak olyan folyamatok, amelyek alacsonyabb kockázattal kezdődhetnek, mielőtt továbblépne az összetettebb folyamatokra?

A gyakori, nagy munkamennyiségű vagy hibalehetőségű folyamatok azonosítása potenciális célként az automatizálás első lépéseként.

Használja az "everything as code" mintát

A Git egyik előnye a mindenütt jelenléte mellett, hogy úgy tervezték, hogy biztonságos és auditálható információforrás legyen. A véglegesítési előzményeken és a hozzáférés-vezérlésen túl az olyan fogalmak, mint a lekéréses kérelmek és az ágvédelem, lehetővé teszik adott véleményezők, beszélgetési előzmények és automatizált ellenőrzések létrehozását, amelyeknek a fő ágba való egyesítés előtt át kell mennie. Ha olyan rugalmas feladatmotorokkal van kombinálva, mint a CI/CD rendszerekben, biztonságos automatizálási keretrendszerrel rendelkezik.

Minden kód mögött az a gondolat áll, hogy szinte bármit fájltá alakíthat egy biztonságos Git-adattárban. Az adattárhoz csatlakoztatott különböző eszközök vagy ügynökök ezután elolvashatják a tartalmat. Ha mindent kódként kezel, az a templating révén segíti az ismételhetőséget, és leegyszerűsíti a fejlesztői önkiszolgálóságot. Tekintsünk át néhány példát arra, hogy ez hogyan működik.

IaC-minták alkalmazása bármely infrastruktúrára

Bár az IaC népszerűvé vált az alkalmazáskézbesítés automatizálásában, a minta minden olyan infrastruktúrára, eszközre vagy szolgáltatásra kiterjed, amelyet ki szeretne építeni és konfigurálni, nem csak az adott alkalmazáshoz kapcsolódókra. Megosztott Kubernetes-fürtök, ahol a Flux telepítve van, valamint olyan eszközök biztosítása, mint például a DataDog, amit több csapat és alkalmazás használ, vagy akár a kedvenc együttműködési eszközeid beállítása.

A működés módja az, hogy van egy különálló, biztonságos központosított adattár, amely egy sor olyan fájlt tartalmaz, amelyek a kiépítendő és konfigurált elemeket képviselik (ebben az esetben bármi, a Bicep-től vagy a Terraformtól a Helm-diagramokig és más natív Kubernetes-formátumokig). Az adattárat egy műveleti csapat vagy más rendszergazdai csoport birtokolja, és a fejlesztők (vagy rendszerek) lekéréses kérelmeket (PRS-eket) küldhetnek. Miután ezek a rendszergazdák egyesítették ezeket a PRs-eket a fő ágba, az alkalmazásfejlesztés során használt CI/CD-eszközök is elindíthatják a módosítások feldolgozását. Tekintse meg az alábbi ábrát, amely az Azure Deployment Environmentsben található GitHub Actions-, IaC- és üzembehelyezési identitásokat mutatja be:

Ha már gitOps-megközelítést használ az alkalmazások üzembe helyezéséhez, ezeket az eszközöket is újra felhasználhatja. Az olyan eszközök kombinálásával, mint a Flux és az Azure Service Operator , lehetővé teszi a Kubernetesen kívüli bővítést:

Mindkét esetben teljes mértékben felügyelt, reprodukálható és naplózható információforrással rendelkezik, még akkor is, ha a létrehozott információ nem egy alkalmazáshoz készült. Az alkalmazásfejlesztéshez hasonlóan a szükséges titkos kulcsokat vagy felügyelt identitásokat a folyamat-/munkafolyamat-motorban vagy a kiépítési szolgáltatás natív képességeiben tárolja a rendszer.

Mivel a PRS-eket készítő személyeknek nincs közvetlen hozzáférésük ezekhez a titkos kódokhoz, lehetővé teszi a fejlesztők számára, hogy biztonságosan kezdeményezhessenek olyan műveleteket, amelyekhez nincs közvetlen engedélyük. Ez lehetővé teszi, hogy betartsa a minimális jogosultság elvét, miközben továbbra is önkiszolgáló lehetőséget biztosít a fejlesztőknek.

Kiépített infrastruktúra nyomon követése

Amikor elkezdi skálázni ezt a megközelítést, gondolja át, hogyan szeretné nyomon követni a kiépített infrastruktúrát. A Git-adattár a konfiguráció igazságforrása, de nem közli a létrehozott konkrét URI-kat és azok állapotinformációit. A kód megközelítésének követésével azonban olyan információforrást kaphat, amelybe koppintva szintetizálhatja a kiépített infrastruktúra készletét. A szolgáltató is jó forrása lehet ennek az információnak, amit elérhet vagy felhasználhat. Az Azure Deployment Environments például olyan környezetkövetési képességeket tartalmaz, amelyekbe a fejlesztők betekintést kaptak.

A különböző adatforrások nyomon követésével kapcsolatos további információkért tekintse meg a fejlesztői önkiszolgáló alaprendszer tervezését ismertető témakört.

A biztonság mint kód és a szabályzat mint kód mintáinak alkalmazása.

Bár az infrastruktúra kiépítése hasznos, fontos, hogy ezek a környezetek biztonságosak legyenek, és általában a szervezet házirendjeinek betartása is ugyanilyen fontos. Ez a szabályzat mint kód koncepció elterjedéséhez vezetett. Itt a forráskonfigurációs adattárban lévő konfigurációs fájlok olyan műveletekre használhatók, mint a biztonsági ellenőrzés vagy az infrastruktúra-szabályzatok alkalmazása.

Ezt a megközelítést számos különböző termék és nyílt forráskódú projekt alkalmazta, többek között az Azure Policy, az Open Policy Agent, a GitHub Advanced Security és a GitHub CODEOWNERS. Az alkalmazásinfrastruktúra, -szolgáltatások vagy -eszközök kiválasztásakor mindenképpen értékelje ki, hogy mennyire támogatják ezeket a mintákat. Az alkalmazás és az irányítás finomításáról további információt az alkalmazásplatform finomítása című témakörben talál.

Használjon mindent kódként a saját forgatókönyveihez

Minden kód kiterjeszti ezeket a mintákat az IaC-t meghaladó automatizálási és konfigurációs feladatok széles körére. Nem csak bármilyen típusú infrastruktúra létrehozását vagy konfigurálását támogatja, hanem az adatok frissítését vagy munkafolyamatok indítását is bármely alárendelt rendszerben.

A PR kiváló alapszintű önkiszolgáló felhasználói élményt nyújt a különböző folyamatokhoz, különösen amikor elkezdi használni őket. A folyamatok természetesen a Git által biztosított biztonsági, auditálási és visszaállítási előnyöket is élvezhetik, és az érintett rendszerek idővel a felhasználói élmény befolyásolása nélkül is változhatnak.

Teams mint kód

Az egyik példa arra, hogy mindent kóddá alakítunk a saját forgatókönyveinkre, a csapatok kezelése kódként. A szervezetek ezt a mintát alkalmazzák a csapattagság és bizonyos esetekben a fejlesztői eszközök/szolgáltatások jogosultságainak szabványosítására a különböző rendszerekben. Ez a minta kiküszöböli a manuális előkészítést és a service desk-folyamatok előkészítését, amelyeket a rendszerfejlesztők és az operátorok saját csoportosítási, felhasználói és hozzáférési fogalmaik elérésének szükségessége vezérel. A manuális ügyfélszolgálati folyamatok biztonsági kockázatot jelenthetnek, mivel a hozzáférés túlterjeszkedhet. Ha a csapatokat kódmintaként használja, a Git és a PRs kombinációja lehetővé teszi az önkiszolgáló szolgáltatást egy naplózható adatforrásból.

Ennek a mintának egy kiforrott, széles körű változatára példaként tekintse meg a GitHub jogosultságok kezeléséről szóló blogbejegyzését. A GitHub nyílt forráskódú, kifinomult Jogosultságok implementációját is kipróbálta vagy bevezette. Bár a blogbejegyzés a teljes körű alkalmazottak jogosultságait ismerteti, a csapatokat kódkoncepcióként alkalmazhatja a szűkebb hatókörű fejlesztői csapat forgatókönyvekre. Előfordulhat, hogy ezek a fejlesztői csapatok egyáltalán nem szerepelnek az alkalmazottak szervezeti diagramjában, és olyan védett eszközöket vagy szolgáltatásokat foglalnak magukba, amelyek megnehezíthetik a csapattagok előkészítését vagy kiléptetését.

Az alábbi összefoglalás egy egyszerűsített változatot mutat be, amely ci-/CD-rendszer- és identitásszolgáltatói csoportokat használ a frissítések koordinálásához:

Ebben a példában:

• Minden érintett rendszer úgy lett beállítva, hogy az identitásszolgáltatót (például a Microsoft Entra ID-t) használja az egyszeri bejelentkezéshez (SSO).
• Identitásszolgáltatói csoportokat (például Entra-csoportokat) használ a rendszerek között a tagság szerepkör szerinti kezelésére, hogy csökkentse az összetettség mértékét, és fenntartsa a központosított naplózást.

Magas szinten a következő módon működik ez a minta:

• Egy központi, zárolt Git-adattárban (általában YAML) található fájlkészlet, amely az egyes absztrakt csapatokat, a kapcsolódó felhasználói tagságot és a felhasználói szerepköröket képviseli. A csapatmódosítások tulajdonosai vagy jóváhagyói is tárolhatók ezen a helyen (például a CODEOWNERSen keresztül). Az ezekben a fájlokban szereplő felhasználóra való hivatkozás az identitásszolgáltató, de ez az adattár az igazság forrása ezeknek a csapatoknak (de nem a felhasználóknak).
• A fájlok minden frissítése lekéréses kérelmeken keresztül történik. Ez összekapcsolja a beszélgetéseket és a hozzá kapcsolódó résztvevőket a Git commithez az auditálhatóság érdekében.
• A vezetők és az egyéni felhasználók PR-ek segítségével adhatnak hozzá vagy távolíthatnak el személyeket, és a fejlesztési vezetők valamint más technikai szerepkörök új csapatokat hozhatnak létre, sablonból származó új csapatfájllal rendelkező PR-ek használatával.
• Amikor egy lekéréses kérelem főbe egyesül, egy, az adattárhoz kapcsolódó CI/CD-rendszer frissíti az identitásszolgáltató rendszert és az összes alsóbb rétegbeli rendszert.

Pontosabban a CI/CD rendszer:

• A megfelelő identitásszolgáltatói rendszer API-val szerepkörenként létrehoz vagy frissít egy identitásszolgáltatói csoportot pontosan a fájlban szereplő személyekkel (nem több, nem kevesebb).
• Api-kat használ minden alárendelt rendszerhez, hogy a rendszercsoportozási koncepciót az egyes szerepkörökhöz (például a GitHubhoz és az Azure DevOpshoz) tartozó szolgáltatócsoportokhoz kösse. Ez egy-az-többhöz kapcsolatot eredményezhet a csapat és a kimeneti rendszer között a szerepkör képviseletéhez.
• (Opcionálisan) Api-kat használ az egyes alsóbb rétegbeli rendszerekhez a rendszer csoportosítási mechanizmusához kapcsolódó engedélylogika implementálásához.
• API használatával frissít egy zárolt adattárat az eredményekkel (beleértve az alsóbb rétegbeli rendszer csapatazonosítóinak társítását is), amelyet aztán bármelyik belsőleg létrehozott rendszerhez felhasználhat. Szükség esetén itt is tárolhat társításokat a felhasználói azonosítók különböző rendszerábrázolásaihoz ugyanazon identitásszolgáltató felhasználóhoz/fiókhoz.

Ha a szervezet már használ hasonló Entra-jogosultságkezelést, előfordulhat, hogy ebből a mintából kihagyhatja a csoporttagság kezelését.

Előfordulhat, hogy az igényei és szabályzatai megváltoztatják a konkrétumokat, de az általános minta tetszőleges számú változathoz igazítható. Az alsóbb rétegbeli rendszerekkel való integrációhoz szükséges titkos kulcsok a CI/CD rendszerben (például a GitHub Actionsben vagy az Azure Pipelinesban) vagy az Azure Key Vaulthoz hasonló módon maradnak fenn.

Manuális vagy külsőleg aktivált, paraméteres munkafolyamatok használata

Előfordulhat, hogy az Ön által azonosított önkiszolgáló problémák némelyike nem segíti elő a gitbeli fájlok használatát. Vagy lehet, hogy rendelkezik egy felhasználói felülettel, amelyet az önkiszolgáló élmény eléréséhez szeretne használni.

Szerencsére a legtöbb CI-rendszer, köztük a GitHub Actions és az Azure Pipelines képes beállítani egy munkafolyamatot bemenetekkel, amelyeket aztán manuálisan aktiválhat a felhasználói felületükön vagy a CLI-iken keresztül. Mivel a fejlesztők és a kapcsolódó operatív szerepkörök valószínűleg már ismerik ezeket a felhasználói tapasztalatokat, a manuális triggerek kiegészíthetik a mindent kódként mintát, hogy automatizálják azokat a tevékenységeket (vagy feladatokat), amelyek vagy nem rendelkeznek természetes fájlreprezentációval, vagy teljesen automatizálhatók anélkül, hogy igényelnék a PR folyamatot.

A CI-rendszer lehetővé teheti, hogy egy API-n keresztül aktiválja ezeket a munkafolyamatokat vagy csővezetékeket a saját felhasználói élményedből. A GitHub Actions esetében ennek a munkának a kulcsa az Actions REST API, amely elindít egy munkafolyamat-küldési eseményt egy munkafolyamat-futtatás elindításához. Az Azure DevOps-eseményindítók hasonlóak, és futtatáshoz használhatja az Azure DevOps Pipeline API-t is. Valószínűleg ugyanazokat a képességeket fogja látni más termékekben is. Akár manuálisan, akár API-val aktiválódik, minden munkafolyamat támogatja a bemenetek készletét, ha workflow_dispatch konfigurációt ad hozzá a munkafolyamat YAML-fájlhoz. Így működnek együtt a portál eszközkészletei, mint például a Backstage.io a GitHub Actions-szel.

A CI/CD-rendszer munkafolyamata vagy feladatrendszere kétségtelenül nyomon követi a tevékenységeket, visszajelezi az állapotot, és részletes naplókkal rendelkezik, amelyeket a fejlesztők és az üzemeltetési csapatok egyaránt használhatnak a hiba megtekintéséhez. Így hasonló biztonsági, naplózási és láthatósági előnyökkel rendelkezik, mint a mindent mint kód minta. Egy dolgot azonban szem előtt kell tartani, hogy az ilyen munkafolyamatok vagy folyamatok által végrehajtott műveletek rendszeridentitásnak (például szolgáltatásnévnek vagy felügyelt identitásnak a Microsoft Entra ID-ban) néznek ki az alsóbb rétegbeli rendszerekhez.

Láthatja, hogy ki kezdeményezi a kéréseket a CI/CD-rendszerben, de érdemes felmérnie, hogy elegendő-e ez az információ, és győződjön meg arról, hogy a CI/CD-adatmegőrzési beállítások megfelelnek a naplózási követelményeknek olyan esetekben, amikor ezek az információk kritikus fontosságúak.

Más esetekben előfordulhat, hogy az integrálható eszközök saját nyomkövetési mechanizmusokkal rendelkeznek, amelyekre támaszkodhat. Ezek a CI/CD-eszközök például szinte mindig számos értesítési mechanizmussal rendelkeznek, például a Microsoft Teams vagy a Slack-csatorna használatával, amelyek lehetővé teszik, hogy bárki figyelemmel kísérhesse az állapotfrissítéseket, és a csatorna nem hivatalos nyilvántartást biztosít a történtekről. Ezeket a munkafolyamat-motorokat gyakran már úgy tervezték, hogy integrálják az üzemeltetési eszközökkel, hogy tovább bővítse ezeknek a mintáknak a hasznosságát.

Összefoglalva, a CI/CD-eszközök rugalmasságának és a könnyen használható felhasználói élménynek köszönhetően a forrásvezérlő-adattárban tárolt fájlok használatával néhány folyamatot automatizálhat. Annak megtekintéséhez, hogy a belső fejlesztői platformok hogyan használhatják ezt a megközelítést kiindulópontként anélkül, hogy idővel a kifinomultabb képességeket veszélyeztetné, tekintse meg a fejlesztői önkiszolgáló alaprendszer kialakítását ismertető témakört.

Fejlesztői kódolási környezetek beállításának automatizálása

A mérnöki rendszerek egy másik gyakori problémája a fejlesztői kódolási környezet rendszerindítása és normalizálása. Íme néhány gyakori probléma, amelyről az alábbi területen hallhat:

• Bizonyos esetekben hetekbe telhet, mire egy fejlesztő elkészíti az első pull-kérését. Ez problémás terület, amikor viszonylag gyakran kell fejlesztőket áthelyezni funkciócsoportok és projektek között (például mátrixos szervezetekben), be kell tanítani az alvállalkozókat, vagy olyan csapatban dolgozol, amely a felvétel fázisában van.
• A fejlesztők és a CI-rendszerek közötti inkonzisztencia gyakori "a gépemen működik" problémákhoz vezethet még a tapasztalt csapattagok esetében is.
• A keretrendszerek, a futtatási idők és más szoftverek kísérletezése és frissítése a meglévő fejlesztői környezeteket is megszakíthatja, és időt veszthet, amikor megpróbálják kitalálni, hogy pontosan mi történt.
• A fejlesztési vezetők esetében a kódellenőrzések lelassíthatják a fejlesztést, mivel azok megkövetelhetik a konfiguráció módosítását a tesztelés céljából, és a felülvizsgálat befejezése után a módosítások visszavonását.
• A csapattagoknak és az üzemeltetőknek a fejlesztésen túli kapcsolódó szerepkörök (operátorok, minőségbiztosítási, üzleti, szponzorok) kiépítésével is időt kell tölteniük, hogy segítsék a tesztelést, az előrehaladást, az üzleti szerepkörök betanítását és a csapat által végzett munka evangelizálását.

A burkolt utak egy része

Ezeknek a problémáknak a megoldásához gondolja át az egyes eszközök és segédprogramok beállítását a jól definiált, burkolt útvonalak részeként. A szkriptelés fejlesztői gépének beállítása segíthet, és ugyanezeket a szkripteket újra felhasználhatja a CI-környezetben. Fontolja meg azonban a tárolóalapú vagy virtualizált fejlesztési környezetek támogatását az általuk nyújtott előnyök miatt. Ezek a kódolási környezetek előre beállíthatók a szervezet vagy a projekt specifikációinak megfelelően.

Munkaállomás cseréje és a Windows megcélzása

Ha a Windowst célozza, vagy teljes munkaállomásvirtualizálást szeretne végezni (az ügyféleszközök és a gazdagép operációs rendszerének beállításai a projektspecifikus beállítások mellett), a virtuális gépek általában a legjobb funkciókat biztosítják. Ezek a környezetek hasznosak lehetnek a Windows-ügyfélfejlesztéstől a Windows-szolgáltatásig, illetve a .NET-keretrendszer teljes körű webalkalmazásainak felügyeletéhez és karbantartásához.

Megközelítés	Példák
Felhőalapú virtuális gépek használata	A Microsoft Dev Box egy teljes windowsos munkaállomásvirtualizálási lehetőség, amely beépített integrációt biztosít az asztali felügyeleti szoftverekkel.
Helyi virtuális gépek használata	A Hashicorp Vagrant egy jó lehetőség, és a HashiCorp Packer használatával virtuálisgép-rendszerképeket készíthet hozzá és a Dev Boxhoz is.

Munkaterület virtualizálása és célzása Linuxon

Ha Linuxot céloz meg, fontolja meg a munkaterület virtualizálási lehetőségét. Ezek a lehetőségek kevésbé összpontosítanak a fejlesztői asztal cseréjére, és inkább a projekt- vagy alkalmazásspecifikus munkaterületekre.

Megközelítés	Példák
Felhőalapú tárolók használata	A GitHub Codespaces a Dev Containers felhőalapú környezete, amely támogatja a VS Code,a JetBrains IntelliJ és a terminálalapú eszközök integrálását. Ha ez vagy egy hasonló szolgáltatás nem felel meg az igényeinek, használhatja a VS Code SSH - vagy távoli alagutak támogatását a Dev Containers használatával távoli Linux rendszerű virtuális gépeken. Az alagútalapú opció, amely nemcsak az ügyféllel, hanem a webalapú vscode.dev-el is működik.
Helyi tárolók használata	Ha inkább egy helyi Dev Containers-beállítást szeretne, vagy egy felhőben üzemeltetett helyett, a Dev Containers szilárd támogatást nyújt a VS Code-ban, az IntelliJ-támogatásban és más eszközökben és szolgáltatásokban.
Felhőalapú virtuális gépek használata	Ha túl korlátozott tárolókat talál, az olyan eszközök SSH-támogatása, mint a VS Code vagy a JetBrains-eszközök, például az IntelliJ, lehetővé teszik, hogy közvetlenül csatlakozzon az Ön által felügyelt Linux rendszerű virtuális gépekhez. A VS Code itt is működik alagútalapú beállítással .
A Linuxhoz készült Windows-alrendszer használata	Ha a fejlesztők kizárólag Windows rendszeren vannak, a Linux Windows-alrendszere (WSL) kiválóan alkalmas arra, hogy a fejlesztők helyileg megcélozza a Linuxot. A WSL-disztribúciót exportálhatja a csapatához, és megoszthatja a beállított összes beállítással. Felhőalapú megoldás esetén a felhőalapú munkaállomás-szolgáltatások, például a Microsoft Dev Box is kihasználhatják a WSL előnyeit a Linux-fejlesztés megcélzásához.

Megfelelő indítási alkalmazássablonok létrehozása, amelyek tartalmazzák a megfelelő konfigurálást

Az "everything as code" mintában az a nagyszerű, hogy a fejlesztőket a kezdetektől fogva a kijelölt utakon tarthatja. Amennyiben ez kihívást jelent a szervezet számára, az alkalmazássablonok gyorsan kulcsfontosságúvá válhatnak az építőelemek újrahasználásához, a konzisztencia elősegítéséhez, a szabványosítás előmozdításához és a szervezet ajánlott eljárásainak kódolásához.

Első lépésként használhat olyan egyszerűt, mint egy GitHub-sablontár, de ha a szervezet monorepómintát követ, ez kevésbé hatékony lehet. Olyan sablonokat is létrehozhat, amelyek segítenek olyan beállításban, amely nem kapcsolódik közvetlenül egy alkalmazás forrásfához. Ehelyett használhat egy olyan templatáló motort, mint a cookiecutter, a Yeoman vagy valami hasonló az Azure Developer CLI (azd), amely a templating és az egyszerűsített CI/CD beállítás mellett a fejlesztői parancsok kényelmes készletét is biztosítja. Mivel az Azure Developer CLI minden forgatókönyvben használható a környezet beállításának ösztönzésére, integrálható az Azure Deployment Environments szolgáltatással a nagyobb biztonság, az integrált IaC, a környezetkövetés, a problémák elkülönítése és az egyszerűsített CD-beállítás érdekében.

Ha már rendelkezik sablonkészlettel, a fejlesztési vezetők ezeket a parancssori eszközöket vagy más integrált felhasználói élményeket használhatják a tartalom alkalmazásaikhoz való felépítéséhez. Mivel azonban előfordulhat, hogy a fejlesztők nem rendelkeznek engedéllyel adattárak vagy más tartalmak létrehozására a sablonokból, ez egy másik lehetőség a manuálisan aktivált, paraméterezett munkafolyamatok vagy folyamatok használatára is. Beállíthatja az inputokat úgy, hogy a CI/CD rendszer bármit létrehozhasson, legyen szó akár egy adattárról vagy infrastruktúráról a nevükben.

A pontosság megtartása és elérése

A skálázás érdekében azonban ezeknek az alkalmazássablonoknak lehetőség szerint központi építőelemekre (például IaC-sablonokra vagy akár CI-/CD-munkafolyamatokra és folyamatokra) kell hivatkoznia. Valójában ezeknek a központosított építőelemeknek a megfelelő kezdősablonok saját formájának kezelése hatékony stratégia lehet az ön által azonosított problémák megoldására.

Ezek az egyéni sablonok nemcsak az új alkalmazásokra alkalmazhatók, hanem a meglévőkre is, amelyeket frissíteni szeretne a frissített vagy továbbfejlesztett irányelvek bevezetése érdekében a megfelelő kampány részeként. Még jobb, hogy ez a központosítás segít megőrizni az új és a meglévő alkalmazásokat is, így idővel fejlesztheti vagy bővítheti ajánlott eljárásait.

Sablon tartalma

A sablonok létrehozásakor a következő területeket javasoljuk figyelembe venni.

Area	Részletek
Elegendő mintaforráskód az alkalmazásminták, az SDK-k és az eszközök használatához	Kód és konfiguráció belefoglalásával a fejlesztőket az ajánlott nyelvek, alkalmazásmodellek és szolgáltatások, API-k, SDK-k és architekturális minták felé irányíthatja. Győződjön meg róla, hogy az Ön által választott eszközökkel készített kód tartalmazza az elosztott nyomkövetést, a naplózást és a megfigyelhetőséget.
Buildelési és üzembehelyezési szkriptek	Biztosítson a fejlesztőknek egy közös módot a buildek és a helyi /tesztkörnyezet üzembe helyezésének elindítására. Az IDE-ben vagy a szerkesztőben adja meg a hibakeresési konfigurációt az Ön által választott eszközökhöz. Ez egy fontos módja annak, hogy elkerüljük a karbantartási fejfájást, és megakadályozzuk a CI/CD szinkronizációs hibáit. Ha a sablonmotor az Azure Developer CLI-hez hasonlóan van szigorúan strukturálva, előfordulhat, hogy már vannak olyan parancsok, amelyeket egyszerűen használhat.
CI/CD konfigurálása	A javaslatok alapján biztosítson munkafolyamatokat/folyamatokat az alkalmazások létrehozásához és üzembe helyezéséhez. Használja ki a központosított, újrafelhasználható és sablonalapú munkafolyamatokat, hogy naprakészek maradjanak. Valójában ezek az újrahasználható munkafolyamatok / csővezetékek saját sablonok kiindulópontjai lehetnek. Mindenképpen fontolja meg a munkafolyamatok manuális aktiválásának lehetőségét.
Infrastruktúra kódegységként	Adjon meg ajánlott IaC-konfigurációkat, beleértve a központilag felügyelt modulokra vagy katalóguselemekre mutató hivatkozásokat, hogy minden infrastruktúra-beállítás kövesse a bevezetés ajánlott eljárásait. Ezek a hivatkozások idővel is segíthetnek abban, hogy a csapatok a helyes úton maradjanak. Munkafolyamatokkal/csővezetékekkel kombinálva az IaC-t vagy az EaC-t is belefoglalhatja, hogy bármit előkészíteni tudjon.
Biztonság és szabályzat kódegységként	A DevSecOps-áthelyezés a biztonsági konfigurációt kódba helyezte, amely nagyszerűen használható sablonokhoz. Egyes szabályzatok mint kódösszetevők alkalmazásszinten is alkalmazhatók. A fájlok, például CODEOWNERS, és az olyan szkennelési konfigurációk, mint a dependabot.yaml, belefoglalhatók a GitHub Advanced Security rendszerbe. Ütemezett munkafolyamatokat és csővezeték-futtatásokat biztosít a vizsgálatokhoz a Defender for Cloud használatával, a környezeti tesztfuttatások végrehajtása mellett. Ez fontos az ellátási lánc biztonsága szempontjából, és mindenképpen vegye figyelembe a tárolórendszerképeket az alkalmazáscsomagok és a kód mellett. Ezek a lépések segítenek a fejlesztői csapatoknak a megfelelő helyen maradni.
Megfigyelhetőség, monitorozás és naplózás	Az önkiszolgáló szolgáltatás engedélyezésének része az alkalmazások egyszerű láthatósága az üzembe helyezés után. A futtatókörnyezeti infrastruktúrán túl ügyeljen arra, hogy a megfigyelhetőség és a figyelés beállítását is tartalmazza. A legtöbb esetben van egy IaC-szempont a beállításhoz (például ügynöktelepítés, rendszerezés), míg más esetekben más típusú konfigurációs kódösszetevő (például az Azure Application Insights monitorozási irányítópultjai). Végül mindenképpen adjon meg kódmintát az elosztott nyomkövetéshez, naplózáshoz és megfigyelhetőséghez a választott eszközökkel.
Kódolási környezet beállítása	Adjon meg konfigurációs fájlokat a linterek, a formázók, a szerkesztők és az IDE-k kódolásához. Tartalmazza a beállítási szkripteket, valamint a munkaterület- vagy munkaállomás-virtualizációs fájlokat, mint például a devcontainer.json, devbox.yaml, fejlesztőközpontú Docker-fájlok, Docker Compose fájlok, vagy Vagrantfiles.
Konfiguráció tesztelése	Adjon meg konfigurációs fájlokat mind egységteszteléshez, mind részletesebb teszteléshez az előnyben részesített szolgáltatások, mint például a Microsoft Playwright Testing a felhasználói interfészhez vagy a Azure App Testing.
Együttműködési eszköz beállítása	Ha a problémakezelő és a forráskövetési rendszer kódként támogatja a feladat- és probléma-/PR-sablonokat, ezeket is tartalmazza. Ha több beállításra van szükség, opcionálisan megadhat egy munkafolyamatot vagy folyamatot, amely egy elérhető CLI vagy API használatával frissíti a rendszereket. Ez lehetővé teszi egyéb együttműködési eszközök, például a Microsoft Teams vagy a Slack beállítását is.

Kapcsolódó tartalom

• A Microsoft DevOps-erőforrásközpontja
• Tárolók biztonságos ellátási lánc keretrendszere
• CI/CD alaparchitektúra az Azure Pipelines használatával
• Az alkalmazásplatform finomítása