Szoftvermérnöki rendszerek alkalmazása

Miután megismerte a platformfejlesztés során először kezelni kívánt problémákat, a fejlesztői önkiszolgáló fejlesztés a lista elejére kerülhet. Az automatizált ö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 ön és a belső ügyfelek számára lesznek ismerősek, hanem számos automatizálási forgatókönyvet is lehetővé tesznek, még akkor is, ha a kezdeti felhasználói élmény nem szép.

Ez a cikk tippeket ad a mérnöki rendszerek alkalmazásához az önkiszolgáló forgatókönyvek szélesebb skáláját kezelő megoldásához, valamint az ajánlott eljárások olyan sablonokba való beágyazásához, 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. Ha azonban nem rendelkezik olyan rendszerrel, amely a DevOps és a DevSecOps fő bérlőinek legalább egy részét célozza meg, az ön által azonosított problémák valószínűleg azt fogják mondani, hogy ott kezdjen. Belső fejlesztői platformok épülnek fel belőlük, hogy csökkentsék a kognitív terhelést minden érintett számára.

Összefoglalva, 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ésben, fejlesztésben, teljesítésben és műveletekben. Célja, hogy javítsa az együttműködést olyan történelmileg silózott szerepkörök között, mint a fejlesztés, az informatikai műveletek, a minőségfejlesztés és a biztonság. Folyamatos hurkot hoz létre a fejlesztés, az üzembe helyezés, a monitorozás, a megfigyelés és a visszajelzés között. A DevSecOps ebbe a hurokba rétegz, és folyamatos biztonsági eljárásokat használ az alkalmazásfejlesztési folyamat során.

A Microsoft DevOps-erőforrásközpontja remek lehetőséget kínál arra, hogy tanácsokat keressen a szükséges folyamatok és rendszerek típusaival kapcsolatban, ezért ebben a szakaszban nem foglalkozunk részletesen ezekkel. Ezek lesznek alapvető összetevők, ahogy halad előre. Ne felejtse el figyelembevenni a legújabb DevSecOps-témaköröket, például a tároló ellátási láncának biztonságát a tervekben.

A folyamatos visszajelzésről további információt a megfontolandó metrikák című témakörben talál. Az alkalmazásplatform finomítása című témakörben további információt talál a megfigyelhetőségi, monitorozási és folyamatos visszajelzési területeken használható eszközökről.

A cikk hátralévő részében a platformmérnöki mozgalomnak közvetlenül tulajdonított fejlesztésekre összpontosítunk: a burkolt útvonalakra, az automatizált infrastruktúra kiépítésére (az alkalmazás üzembe helyezésén kívül), a kódolási környezet beállítására, valamint az eszközök, csapategységek és szolgáltatások önkiszolgáló kiépítésére és konfigurálására, amelyek nem közvetlenül részei az alkalmazásfejlesztési ciklusnak.

A kívánt térkövezett ú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 a kezdeti platformmérnöki erőfeszítések részeként szeretné-e ezeket konszolidálni, vagy a kezdetektől fogva támogatja a különböző eszközök konstellációját. A legtöbb esetben az eszközök konstellációjában található térkövezett útvonalak meghatározása a leghatékonyabb, és nagyobb rugalmasságot biztosít.

Amikor a termékszemlére vált, az ezeken a burkolt útvonalakon belüli mérnöki rendszerek olyan eszközökből állnak, amelyek központilag, a fejlesztői csapatok szolgáltatásaként vannak kezelve. A szervezeten belüli egyes csapatok vagy részlegek eltérhetnek egymástól, de az eszközök kezelését, karbantartását és kifizetését külön kell majd kezelniük, karbantartani és fizetniük, 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 útba való lehetséges belefoglalástól az idő múlásával. Az egyik platformmérnöki vezető a következőt fogalmazta meg:

Még mindig megteheti a saját dolgát, de olyan irányba, a mi megyünk... bármit megváltoztathat, de ez az Ön felelőssége lesz. Öné a változások – a saját éles kések. - Mark, platformmérnöki vezető, Large European Multinational Retail Company

Tekintettel arra, hogy a platformfejlesztés egyik fő célja a termékszemléletre való áttérés, ahol értéket ad a belső ügyfeleknek, ez a konstellációs megközelítés általában jobban működik, mint egy felülről lefelé irányuló megbízás. Ahogy kialakítja és finomítja a kikövezett útvonalakat, némi rugalmasságot hagyva lehetővé teszi a csapatok számára, hogy bemenetet adjanak, és kielégítse az adott alkalmazás minden igazán egyedi követelményét anélkül, hogy a szervezet más tagjait érintenék. Ez teljesen kikövezett, aranyozott utakhoz vezet, míg mások csak részben kövezettek. Azokban az esetekben, amikor nincsenek egyedi követelmények, a további munka fejlesztői csapatai természetesen azt fogják eredményezni, hogy idővel egy támogatott útvonalra szeretnének váltani.

Ha inkább konszolidációs stratégiát szeretne, vegye figyelembe, hogy a meglévő alkalmazások migrálása a vártnál több munkát jelenthet, ezért a kezdéshez valószínűleg a terület megfelelő kezdési aspektusára kell összpontosítania, és új projektekre kell összpontosítania. Ez megadja az első kikövezett utat, miközben minden meglévő eredendően nem készül el. A nem előkészített útvonal fejlesztői csapatai ezután megfontolják az áthelyezést, miután az új kikövezett útvonal megjeleníti annak értékét a szervezet számára. Ezen a ponton futtathat egy megfelelő kampányt, hogy mindenki a kívánt állapotban legyen kétirányú kommunikációval, mivel a fejlesztői csapatok ezt előnyként, nem pedig adóként tekintik. 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 a kikövezett útvonalak jobbá tétele érdekében.

Ettől függetlenül próbálja meg elkerülni a burkolt útvonalak használatát. A leghatékonyabb módja annak, hogy kihangsúlyozza, milyen csapatok kerülnek ki belőlük a kényszerített bevezetés helyett. Mivel a belső fejlesztői platform arra összpontosít, hogy pontosan ugyanazokat a csapatokat boldoggá, költségvetés és idő-érték arány nyomás az egyes vezetők általában gondoskodik a többi. Szerezze be a megfelelő kampányokat, majd biztosítson egy utat a kétirányú beszélgetésekhez a legjobb módon azok számára, akik egy meg nem oldott útvonalon váltanak.

Fejlesztői automatizálási eszközök használata a kikövezett ú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 engedélyezése folyamatos teljesítés közben

Ha még nincs implementálva, 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). Az olyan termékek, mint a GitHub Actions, az Azure DevOps, a Jenkins, valamint a lekéréses gitOps-megoldások, mint a Flux vagy az Argo CD, ezen a téren léteznek. Ezekről a témakörökről a Microsoft DevOps erőforrásközpontban olvashat.

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

Vegyük például ezeket az ábrákat, amelyek két megközelítést mutatnak be, amelyek GitHub Actions használnak az infrastruktúra frissítéséhez és az Azure Kubernetes Service való üzembe helyezéshez: az egyik leküldéses üzemelő példányokat használ, a másik a lekéréses alapú (GitOps) üzemelő példányokat.

Az egyes megközelítésekről további információt a CI/CD for AKS-alkalmazások GitHub Actions és a Gitflow használatával című témakörben talál.

A kiválasztott lehetőségeket gyakran a meglévő IaC-képességkészlet és a célalkalmazási platform részletei határozzák meg. A GitOps-megközelítés a legújabb, és népszerű a Kubernetes-t használó szervezetek körében az alkalmazásaik bázisaként, míg a lekéréses alapú modell jelenleg a lehető legtöbb rugalmasságot biztosítja a rendelkezésre álló lehetőségek számának megfelelően. Azt várjuk, hogy a legtöbb szervezet a kettő kombinációját fogja használni. Függetlenül attól, hogy jól ismeri az IaC-eljárásokat, könnyebben elsajátíthatja a további automatizálási forgatókönyvekre vonatkozó mintákat.

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 újrafelhasználás céljából. 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 Azure Container Registry (ACR) vagy DockerHub, 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ás-definíciók, mint például az Azure Service Operator , további támogatást nyújthatnak más típusú Azure-erőforrásokhoz, más eszközökhöz, például a Többsíkú támogatási erőforrásokhoz több felhőben. Ezek lehetővé teszik a központosított vagy gyakori Helm-diagramok használatát az ACR-hez hasonló módon a forgatókönyvek szélesebb halmazához.

Az IaC központosítása azáltal javítja a biztonságot, hogy jobban szabályozhatja, hogy ki végezhet frissítéseket, mivel azok már nem alkalmazáskóddal vannak tárolva. A kódfrissítések során a szakértők, a műveletek vagy a platformmérnökök a szükséges módosítások végrehajtásakor kisebb kockázatot jelentenek a véletlen törések miatt. A fejlesztők emellett kihasználhatják 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 legújabb kísérleti Radius OSS-inkubációs projekt például inkább véleményezett, mint a Kubernetes közvetlen használata, de a fejlesztői élményt is leegyszerűsíti. A Felhőszolgáltatástípusok leírása betanítási modul segít megérteni a különböző modellek előnyeit és hátrányait. Függetlenül attól, hogy a központi és felügyelt IaC-ra való hivatkozás ahelyett, hogy teljes definíciókat tartalmaz a forrásfán, 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 ne férhessenek hozzá közvetlenül az irányítás alapvető építőelemeibe. 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 hozzáadhatnak felügyelt identitásokat és előfizetéseket a "környezet típusa" szerint, é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 a 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 ADE-t használ, akár nem, a választott folyamatos kézbesítési rendszer biztonságosan és biztonságosan frissítheti az infrastruktúrát a titkos kódok elkülönítésével és az IaC-tartalom forrásának olyan helyekről való elkülönítésével, amelyekhez a fejlesztők nem férhetnek hozzá és nem módosíthatják őket.

Az önkiszolgáló szolgáltatás engedélyezése az alkalmazások folyamatos kézbesítésén túli helyzetekben

Bár a CI- és CD-fogalmak az alkalmazásfejlesztéshez kapcsolódnak, a belső ügyfelek által kiépíteni kívánt dolgok 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.

Annak megértéséhez, hogy ez hol segíthet, gondolja át, hogy jelenleg hol vannak manuális vagy ügyfélszolgálati alapú folyamatai. Mindegyik esetében gondolja át ezeket a kérdéseket:

• Milyen gyakran történik ez a folyamat?
• Lassú a folyamat, a hiba hajlamos, vagy jelentős munka szükséges az eléréséhez?
• 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?
• Ha jóváhagyóra van szükség, ismerik a forrásvezérlő rendszereket és a lekéréses kérelmek folyamatait?
• 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, amelyekkel alacsonyabb kockázattal kezdhet, mielőtt továbblépne az összetettebb folyamatokra?

A gyakori, nagy erőfeszítéssel vagy hibával járó folyamatokat azonosíthatja potenciális célként az automatizálás első lépéseként. A következő lépésben bemutatunk néhány egyszerű módszert, hogy ez megtörténjen.

Minden használata kódmintaként

Az egyik szép dolog a git mellett a mindenütt jelen van, hogy célja, hogy egy biztonságos, naplózható információforrás. 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 a ágvédelem, lehetővé teszik adott felülvizsgálók, beszélgetési előzmények és automatizált ellenőrzések létrehozását, amelyeket a fő ágba való egyesítés előtt át kell adni. A CI/CD rendszerekben találhatóhoz hasonló rugalmas feladatmotorokkal kombinálva 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 csábítással 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ások kézbesítésének 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. Például megosztottA K8-okat olyan fürtekkel, amelyeken telepítve van a Flux, kiépíthet például egy, a Több csapat és alkalmazás által használt DataDoghoz hasonlót, vagy akár a kedvenc együttműködési eszközeit is.

Ennek az a módja, hogy egy különálló, biztonságos központosított adattárral rendelkezik, amely egy sor olyan fájlt tartalmaz, amelyek a kiosztandó és konfigurálni kívánt elemeket felelnek meg (ebben az esetben a Biceptől, a Terraformtól a Helm-diagramokig és más Kubernetes-natív formátumokig). Az adattár egy üzemeltetési csapat vagy más rendszergazdai csoport tulajdonában van, és a fejlesztők (vagy rendszerek) lekéréses kérelmeket küldhetnek. Miután ezeket a KÉRELEM-eket a rendszergazdák egyesítették a főágban, az alkalmazásfejlesztés során használt CI/CD-eszközök elindíthatják a módosítások feldolgozását. Tekintse át ezt az ábrát, amely GitHub Actions és IaC- és üzembehelyezési identitásokat használ az Azure-beli üzembehelyezési környezetekben:

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 terjeszkedést:

Mindkét esetben teljes körűen 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 kulcsok vagy felügyelt identitások tárolhatók a folyamat-/munkafolyamat-motorban vagy egy kiépítési szolgáltatás natív képességeiben.

Mivel a lekéréses kérelmeket készítő személyek nem férhetnek hozzá közvetlenül ezekhez a titkos kódokhoz, a fejlesztők biztonságosan kezdeményezhetnek 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

Ahogy 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 adja meg a létrehozott URI-kkal és állapotinformációkkal kapcsolatos információkat. Ha azonban mindent kódként követ, az információforrást a kiépített infrastruktúra leltárának szintetizálásához használhatja. A kiépítési eszköz is jó forrása lehet ennek az információnak, amelybe koppinthat. Az Azure-beli üzembehelyezési környezetek például olyan környezetkövetési képességeket tartalmaznak, amelyekbe a fejlesztők betekintést láthatnak.

A különböző adatforrások közötti nyomon követéssel kapcsolatos további információkért lásd: Fejlesztői önkiszolgáló alaprendszer megtervezése.

A biztonság alkalmazása kódként és szabályzatként kódmintákként

Bár az infrastruktúra kiépítése hasznos, ugyanilyen fontos, hogy ezek a környezetek biztonságosak legyenek, és általában a szervezet házirendjeinek követése legyen. Ez a "szabályzat mint kód" koncepció növekedéséhez vezetett. Itt a verziókövetési adattárakban található konfigurációs fájlok olyan műveletekre használhatók, mint a meghajtóbiztonsági vizsgálat vagy az infrastruktúra-szabályzatok alkalmazása.

Számos különböző termék és nyílt forráskód projekt támogatja ezt a megközelítést, többek között Azure Policy, open policy agent, GitHub Advanced Security és GitHub CODEOWNERS. Az alkalmazás-infrastruktú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ával kapcsolatos további információkért lásd: Az alkalmazásplatform finomítása.

Minden használata 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 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 lekéréses kérelem jó kiindulási alapként szolgál a különböző folyamatok önkiszolgáló felhasználói élményéhez – különösen az első lépések során. A folyamatok természetesen élvezhetik a git által nyújtott biztonsági, naplózási és visszaállítási előnyöket, és az érintett rendszerek idővel a felhasználói élmény befolyásolása nélkül is változhatnak.

Teams kódként

Egy példa arra, hogy minden kódként alkalmazható a saját forgatókönyvekre, a csapatok kódmintaként. A szervezetek ezt a mintát alkalmazzák a csapattagság és bizonyos esetekben a fejlesztői eszközök/szolgáltatásjogosultságok szabványosítására a különböző rendszerekben. Ez a minta kiküszöböli az ügyfélszolgálati folyamatok manuális előkészítését és kivezeté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 lekéréses kérelmek 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ű variációjá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ű alkalmazotti jogosultságokat ismerteti, a csapatokat kódkoncepcióként alkalmazhatja a szűkebb hatókörű fejlesztői csapat forgatókönyveihez. Előfordulhat, hogy ezek a fejlesztői csapatok egyáltalán nem jelennek meg az alkalmazottak szervezeti diagramján, és olyan saját fejlesztésű eszközöket vagy szolgáltatásokat foglalnak magukba, amelyek megnehezíthetik a csapattagok előkészítését vagy kivezetését.

Az alábbiakban összefoglaljuk ennek az elképzelésnek egy egyszerűsített változatát, amely EGY CI/CD rendszer- és identitásszolgáltatói csoportokat használ a frissítések koordinálásához:

Ebben a példában a következőket feltételezzük:

1. Minden érintett rendszer úgy van beállítva, hogy az identitásszolgáltatót (például Microsoft Entra ID) használja az egyszeri bejelentkezéshez (SSO).
2. Identitásszolgáltatói csoportokat (például Entra-csoportokat) fog használni a rendszerekben a tagság szerepkör szerinti kezeléséhez a bonyolultság csökkentése és a központosított naplózás fenntartása érdekében.

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

1. Egy központi, zárolt Git-adattárban (általában YAML) található fájlok készlete, amelyek az egyes absztrakt csapatokat, a kapcsolódó felhasználói tagságot és a felhasználói szerepköröket képviselik. A csapatmódosítások tulajdonosai/jóváhagyói ugyanazon a helyen is tárolhatók (például a CODEOWNERS használatával). A fájlokban szereplő felhasználóra való hivatkozás az identitásszolgáltató, de ez az adattár az igazság forrásaként szolgál ezeknek a csapatoknak (de a felhasználóknak nem).
2. A többi kódesethez hasonlóan ezen fájlok összes frissítése lekéréses kérelmeken keresztül történik. Ez összekapcsolja a beszélgetéseket és a kapcsolódó résztvevőket a git-véglegesítési kérelemhez a naplózás érdekében.
3. Az érdeklődők és az egyes felhasználók lekéréses kérelmeket hozhatnak létre személyek hozzáadásához/eltávolításához, a fejlesztői érdeklődők és más szerepkörök pedig új csapatokat hozhatnak létre olyan lekéréses kérelmekkel, amelyek egy új csapatfájllal egy sablonból származnak.
4. A lekéréses kérelem főbe egyesítésekor az adattárhoz kapcsolódó CI/CD-rendszer frissíti az identitásszolgáltató rendszert és az összes alárendelt rendszert.

Pontosabban a CI/CD rendszer:

5. A megfelelő identitásszolgáltatói rendszer API-val szerepkörenként hoz létre vagy frissít egy identitásszolgáltatói csoportot pontosan a fájlban szereplő személyekkel (nem több, nem kevesebb).
6. Api-kat használ az egyes alárendelt rendszerekhez, hogy ezeket a rendszercsoportozási fogalmakat az egyes szerepkörökhöz tartozó szolgáltatói csoportokhoz (például a GitHubhoz és az Azure DevOpshoz) kösse. Ez egy-a-többhöz kapcsolatot eredményezhet a csapat és az alárendelt rendszer között, hogy egy szerepkört képviseljen.
7. Igény szerint api-kat használ minden alsóbb rétegbeli rendszerhez a rendszer csoportosítási mechanizmusához kötött engedélylogika implementálásához.
8. API-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), amelyet aztán felhasználhat a belsőleg létrehozott rendszerek bármelyikéhez. A felhasználói azonosítók különböző rendszerképleteihez tartozó társításokat is tárolhatja ugyanahhoz az identitásszolgáltató felhasználóhoz/fiókhoz, ha szükséges.

Vegye figyelembe, hogy ha szervezete már az Entra-jogosultságkezeléshez hasonlót használ, akkor kihagyhatja a csoporttagság kezelését ebből a mintából.

Előfordulhat, hogy az igényei és a 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áláshoz szükséges titkos kódokat vagy a CI/CD rendszerben (például GitHub Actions,Azure Pipelinesban) vagy az Azure Key Vault-ban tartják fenn.

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

Az Ön által azonosított önkiszolgáló problémák némelyike nem biztos, hogy elősegíti a fájlok használatát a Gitben. Vagy lehet, hogy rendelkezik egy felhasználói felülettel, amelyet az önkiszolgáló élményhez 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ó műveleti szerepkörök valószínűleg már ismerik ezeket a felhasználói élményeket, a manuális triggerek kódmintaként bővíthetik a kódot, hogy lehetővé tegyék az automatizálást olyan tevékenységek (vagy feladatok) esetében, amelyek vagy nem rendelkeznek természetes fájlmegjelenítéssel, vagy teljes mértékben automatizálhatók lekéréses folyamat megkövetelése nélkül.

Sőt, a CI-rendszer lehetővé teheti, hogy egy API-val aktiválja ezeket a munkafolyamatokat/ folyamatokat a saját felhasználói élményébő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 az Azure DevOps Pipeline API-t futtatásokhoz is használhatja. 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 egy készletét, ha hozzáad egy workflow_dispatch konfigurációt a munkafolyamat YAML-fájlhoz. Így működnek például a portál eszközkészletei, például Backstage.io a GitHub Actions.

A CI/CD-rendszer munkafolyamat-/feladatrendszere kétségtelenül nyomon követi a tevékenységeket, állapotjelentéseket készít, és részletes naplókkal rendelkezik, amelyek segítségével a fejlesztők és az üzemeltetési csapatok is láthatják, hogy mi történt. Ily módon ugyanazokkal a biztonsági, naplózási és láthatósági előnyökkel rendelkezik, mint a kódminta. Egy dolgot azonban szem előtt kell tartani, hogy a munkafolyamatok/folyamatok által végrehajtott műveletek rendszeridentitásként (például szolgáltatásnévként vagy felügyelt identitásként jelennek meg Microsoft Entra ID) az alsóbb rétegbeli rendszerekhez.

Láthatja, hogy ki kezdeményezi a kéréseket a CI/CD-rendszerben, de fel kell mérnie, hogy ez elegendő információ-e, é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 az integrálható eszközök saját nyomkövetési mechanizmusokkal rendelkezhetnek, 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 küldjön be egy kérést az állapotfrissítések lekéréséhez, és a csatorna informálisan rögzíti a történteket. 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 beépített felhasználói élménynek köszönhetően implementálhat némi automatizálást a forráskövetési adattárban tárolt fájlok használatával.

Annak megtekintéséhez, hogy a belső fejlesztői platformok hogyan használhatják ezt a megközelítést kiindulási pontként anélkül, hogy az idő múlásával veszélyeztetné a kifinomultabb képességeket, tekintse meg a fejlesztői önkiszolgáló alaprendszer kialakítását ismertető cikket.

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

Egy másik gyakori probléma, amelyet a mérnöki rendszerek segíthetnek, a fejlesztői kódolási környezet rendszerindítása és normalizálása. Íme néhány gyakori probléma, amelyekről ezen a területen hallhat:

• Bizonyos esetekben hetekbe telhet, hogy a fejlesztők megkapják az első lekéréses kérelmet. Ez egy problémás terület, ha a fejlesztőket viszonylag gyakran (például mátrixos szervezetekben) továbbítja a fejlesztőket a funkciócsapatok és a projektek között, alvállalkozókat kell felrámolnia, vagy egy olyan csapatban kell dolgoznia, amely egy felvételi fázisban van.
• A fejlesztők és a CI-rendszerek közötti inkonzisztencia a tapasztalt csapattagok esetében is gyakori "működik a gépemen" problémákhoz vezethet.
• A keretrendszerek, a futtatási idők és más szoftverek kísérletezése és frissítése megszakíthatja a meglévő fejlesztői környezeteket, és időt veszthet, amikor megpróbálja kitalálni, hogy pontosan mi történt.
• Fejlesztői érdeklődők esetén a kódvizsgálatok lelassíthatják a fejlesztést, mivel a felülvizsgálat után konfigurációmódosításra lehet szükség a teszteléshez és a visszavonásukhoz.
• A csapattagoknak és az üzemeltetőknek időt kell fordítaniuk a fejlesztésen túli kapcsolódó szerepkörök (operátorok, minőségbiztosítási, üzleti, szponzorok) fejlesztésére, hogy segítsenek a tesztelésben, az előrehaladás megtekintésében, az üzleti szerepkörök betanításában és a csapat által végzett munka evangelizálásában.

A kikövezett utak egy része

Ezeknek a problémáknak a megoldásához a jól definiált térkövezett útvonalak részeként gondolja át az egyes eszközök és segédprogramok beállítását. 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 célzása

Ha a Windowst célozza meg, 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 teljes keretrendszerű webalkalmazásainak kezeléséhez és karbantartásához.

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

Ha Linuxot céloz meg, fontolja meg a munkaterület virtualizálásá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.

Megfelelő indítási jogosultságú alkalmazássablonok létrehozása, amelyek tartalmazzák a megfelelő konfigurációt

A kódmintaként létrehozott összes dologban az a nagyszerű, hogy a fejlesztőket az elejétől fogva kialakított kikövezett útvonalakon tarthatja. Ha ez kihívást jelent a szervezet számára, az alkalmazássablonok gyorsan kritikussá válhatnak az építőelemeknek a konzisztencia fokozása, a szabványosítás előmozdítása és a szervezet ajánlott eljárásainak kódolása érdekében.

Első lépésként használhat valami olyan egyszerűt, mint egy GitHub-sablonadattár, de ha a szervezet monorepo 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 templating 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 a Azure Developer CLI a környezet beállításának ösztönzésére használható minden forgatókönyvben, integrálható az Azure Deployment Environments szolgáltatással, így nagyobb biztonságot, integrált IaC-t, környezetkövetést, az aggodalmak elkülönítését és egyszerűsített CD-beállításokat biztosít.

Ha már rendelkezik sablonkészlettel, a fejlesztői érdeklődők ezeket a parancssori eszközöket vagy más integrált felhasználói felületeket használhatják a tartalomnak az alkalmazásaikhoz való kialakításához. Mivel azonban előfordulhat, hogy a fejlesztők nem rendelkeznek engedéllyel adattárak vagy más tartalmak létrehozásához a sablonokból, ez egy másik lehetőség a manuálisan aktivált, paraméteres munkafolyamatok / folyamatok használatára is. Beállíthatja, hogy a CI/CD-rendszer bármit létrehozhasson egy adattárból az infrastruktúrába a nevükben.

Jobb és jobb szerzés

A skálázás érdekében azonban ezeknek az alkalmazássablonoknak a központosított építőelemekre kell hivatkoznia, ahol csak lehetséges (például IaC-sablonok vagy akár CI/CD-munkafolyamatok/ folyamatok). Sőt, azt is tapasztalhatja, hogy ezeknek a központosított építőelemeknek a saját kezdősablonokként való kezelése hatékony stratégia az Ön által azonosított problémák megoldására.

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

Sablon tartalma

Sablonok létrehozásakor az alábbi területeket javasoljuk figyelembe venni.