Fejlesztői önkiszolgáló alaprendszer megtervezése

Ha már jól ismeri a mérnöki rendszerek célrendszereit, elkezdhet kifinomultabb fejlesztői önkiszolgáló élményeket létrehozni. Ebben a szakaszban egy olyan fogalmi architektúrát ismertetünk, amely rugalmas alapot teremt a termékek létrehozásához vagy értékeléséhez. Ezeket a fogalmakat, mintákat és összetevőket együttesen fejlesztői önkiszolgáló alapként tekintjük.

Bár előfordulhat, hogy ma nem kell mindent leírnia a szervezetében, ezeket a fogalmakat érdemes szem előtt tartania, ha egyéni termékeket készít, vagy kiértékeli a kapcsolódó termékeket. Az Ön világában ez a modell a saját termesztésű, a polcon kívüli és a nyílt forráskódú termékek kombinációjából áll. A termékek vagy a nyílt forráskódú portál eszközkészletei, például a Backstage.io eltérő kifejezéseket használhatnak az ebben a szakaszban ismertetett modell egyes elemeihez, de a modell továbbra is segíthet a tájékozódásban.

Goals és megfontolandó szempontok

Ezen a területen végzett erőfeszítéseinek fő célja az önkiszolgáló, védőkorlátokkal történő önkiszolgáló működés biztosítása szabályozott, szabályozott feladatvégrehajtással és kiépítéssel, valamint a központosított láthatósággal. A leggyakrabban a legértékesebb területek azok, amelyek fárasztóak, vagy olyan dolgok, amelyekre a fejlesztő nem képes az összetettség vagy az engedélyek miatt. Ez az utolsó darab azért fontos, hogy a legkisebb jogosultság elvét kövesse anélkül, hogy a fejlesztőket manuális ügyfélszolgálati folyamaton keresztül kényszerítenének.

Bár dönthet úgy, hogy kibővíti DevOps-csomagját, hogy megfeleljen ezeknek az igényeknek, idővel valószínűleg több alkalmazásplatformot is támogatnia kell, és az őket támogató konkrét eszközöket és folyamatokat is módosítania kell. Az alapvető probléma az, hogy a szabványok egy mozgó cél. Ahogy az egyik platformmérnök elmondta:

A nehézségek közé tartozik a szabványosítás ... és a "magára hagyás" kezelése... A szabványosítás gyakran nem érhető el az automatizált folyamatok esetleges megszakadása és a szükséges módosítások azonosításának időigényes feladata miatt. - Martin, DevOps-mérnök, Large Logistics Company

Ahogy ez az idézet is kiemeli, az új vagy frissített szabványra való gyors váltás általában nem kivitelezhető, és a meglévő folyamatok elhagyása kockázatot jelent. Előfordulhat, hogy a szervezet már több DevOps-csomagot vagy különböző kombinációkat használ az egyes eszközök és fejlesztői szolgáltatások esetében. Még egy központi csapattal és egy standard megoldással is, az önkiszolgáló igények növekedésével a variabilitás elkerülhetetlen. Ezért érdemes engedélyeznie az ellenőrzött kísérletezést, ahol a kijelölt csapatok kipróbálhatnak új technológiákat, üzembehelyezési stratégiákat és így tovább, amelyeket szándékos bevezetés és növekményes bevezetés követ.

Az önkiszolgáló szolgáltatások általában két elsődleges kategóriába sorolhatók:

• Automation
• Adatösszesítés

Bár az adatösszesítés jó felhasználói élményt teremt, ahogy azt egy platformmérnök fogalmazta meg:

Az automatizálás kulcsfontosságú, és mindenki imádni fogja. Az [Data] összesítés másodlagos. – Peter, platformmérnöki vezető, multinacionális technológiai vállalat

Ezért valószínű, hogy a diagramon szereplő platformmérnöki folyamat azonosított néhány olyan problémát, amelyet automatizálással meg lehet oldani. A kognitív terhelés és a fejlesztői terhelés csökkentése mellett az automatizálás azt is lehetővé teszi, hogy az alkalmazások a műveletek, a biztonság és más szerepkörök legjobb eszközeihez és szolgáltatásaihoz csatlakozhassanak a munkájuk elvégzéséhez.

Ha azonban több rendszerrel dolgozik az automatizálás érdekében, bizonyos szintű adatösszesítés hasznos lehet az automatizált kérések és a kapcsolódó eredmények nyomon követéséhez. Gyakran előfordulhat, hogy külső rendszerekre hivatkozik, hogy kielégítse az egyéb igényeket, vagy részletezi a részleteket. Az adatösszesítés és a láthatóság szintén fontos a naplózás, a szabályozás és a hulladék csökkentése szempontjából (például: nem használt környezetek).

Az infrastruktúra-kiépítés automatizálása rendszerintegrációk használatával is elvégezhető, de a fejlesztők számára automatizáltnak tűnő manuális munkafolyamatot is elindíthat és megkönnyíthet. Ez hasznos a platform korai szakaszaiban, az ökoszisztémába behozott új termékeknél, vagy olyan területeken, ahol nem vagy nem tud automatizálni egy rendszert (például szoftverlicenc-hozzárendelést). A megfelelő kialakítással egy olyan manuális folyamattal kezdhet, amelyet a Power Automate-hez hasonló folyamat tesz lehetővé, amelyet idővel teljesen automatizált folyamatra válthat át. Így már a kezdetektől tervezhet automatizálást.

A termékszemléllyel és a legvékonyabb működőképes platform (TVP) ( a platform MVP-jének ) ötlete alapján először egyszerűnek kell lennie a meglévő beruházások, például a mérnöki rendszerek vagy egy belső portál újrahasználatával, majd a CLI-k, az alapszintű weblapok vagy akár a Power Pages, a Power BI vagy a Microsoft Fabric irányítópultjainak létrehozásával és igény szerinti bővítésével. Ezt szem előtt tartva az UX által használt konzisztens API segítségével idővel több felületet is támogathat, ahogy változnak az igényei és a preferenciái.

Fogalmak áttekintése

Vegye figyelembe a következő ábrát:

Ahogy az ábrán látható, a következő összetevők alkotják a fejlesztői önkiszolgáló alapfogalom lényegét:

Ezek az alapvető összetevők lehetővé teszik a különböző építőelemek időbeli használatát és felcserélésére. Ezeket részletesebben is megismerjük a következő szakaszokban.

Fel kell építenem mindezt az első lépésekhez?

Nem. Először is, ez egy fogalmi modell, amely segít átgondolni, hogy egy ilyen alapnak mire kell képesnek lennie, ha elkészült. Másodszor, a megvalósítási jellemzők itt kevésbé fontosak, mivel a fejlesztői platform API lesz a fő felület. Előfordulhat, hogy a kezdeti implementáció a kódban szereplő felületek és osztályok használatával indul el a leírt különböző rétegekhez, vagy más termékekben vegyesen jelenik meg. A szempontokat is kihagyhatja, mert az ügyfélfejlesztés azt jelzi, hogy ez egyszerűen egy alacsonyabb prioritás. Kezdje azzal, ami van, és növekszik.

Ezt szem előtt tartva ássunk mélyebbre az egyes darabokat.

Fejlesztői platform API

Meg kell határoznia egy fejlesztői platform API-t, hogy a rendszer szerződéseként működjön. Az API-t különböző felhasználói felületek használják az adathozzáférés engedélyezéséhez, illetve a meghajtók kiépítéséhez és más műveletekhez.

Ennek az API-nak fontos hitelesítési és biztonsági rétegként is működnie kell, mivel a más rendszerekben lévő nyers mögöttes API-khoz való hozzáférést konkrétabb, ellenőrzött adatokra és műveletekre korlátozza. Az API hozzáférést biztosít a felhasználói profil saját reprezentációjához, a felhasználó platformon belüli magas szintű szerepköréhez (csapattag, rendszergazda stb.) és az elsődleges identitásszolgáltató rendszerazonosítóihoz. További információ: Felhasználók és csapatok.

Fejlesztői platformszolgáltatók

A belső fejlesztői platform szélességét figyelembe véve javasoljuk, hogy olyan rendszereket hozzon létre vagy keressen, amelyek egy bővíthető szolgáltatói modellt követnek, hogy funkciókat vezessenek be az API-ba. Az ötlet az, hogy az olyan kulcsfontosságú funkciók, mint az automatizálás és az adatösszesítés, a jól definiált interfészekkel rendelkező csatlakoztatható összetevőkkel való interakcióval biztosíthatók. Ez a laza csatolás segít a szükséges növekményes bekötésben, és javítja a karbantarthatóságot, mivel az alaptól függetlenül tesztelheti a funkciókat.

Ez egy fontos módja annak is, hogy skálázható belső forrás mentalitást biztosítsunk a platform számára. A platformfejlesztéssel kapcsolatos belső forrásbeszerzési erőfeszítések általában nem nyernek vontatást a folyamatos karbantartással kapcsolatos kihívások miatt. Előfordulhat, hogy más csapatok is hajlandóak a funkciókkal hozzájárulni, de kevésbé valószínű, hogy hajlandóak fenntartani és tesztelni valamit a platform magjában. Ezzel szemben minden központosított csapat korlátozott kapacitással rendelkezik a közzétett kód karbantartására vagy akár a lekéréses kérelmek áttekintésére. A fejlesztői platformszolgáltató fogalma enyhíti ezt a feszültséget azáltal, hogy lehetővé teszi a független írású kódnak, hogy a fejlesztői önkiszolgáló alaprendszer alapvető funkcióihoz "csatlakoztasson". Bár körültekintően kell kezelnie, hogy mely szolgáltatókat használja, tekintse át a szolgáltatói kódot, és korlátozza az adott szolgáltató által a fejlesztői platformon elérhető felületi területet, a csatlakoztatható megközelítéssel a szervezet szélesebb körére skálázhatja a munkát.

A fejlesztői platform szolgáltatói alapfogalmai

Entitások

Az entitás fogalma olyan dolog, amelyet a belső fejlesztői platform fejlesztőinek vagy más rendszereinek nyomon kell követnie, frissítenie, bemutatnia vagy cselekednie kell. Az entitások kapcsolatban állhatnak egymással, amelyek együttesen alkotnak egy grafikont , amely kritikus információkat nyújt a belső fejlesztői platform egyes részeiről. A fejlesztői platformszolgáltatók ezután entitásokat adhatnak ki az alapvető képességek engedélyezéséhez, beleértve a következőket:

• Külsőleg kiépített erőforrások/környezetek vagy elérhető API-k felderítése és használata
• Kapcsolatok felfedése függőségelemzéshez, hatáselemzéshez, felderítéshez stb.
• Felderítési és együttműködési célú felületi karbantartó/tulajdonosi információk
• További adatok böngészése a felhasználói élményben való használathoz

Ennek a funkciónak a jól definiált fejlesztői platformszolgáltatói felületbe való beágyazása leegyszerűsíti az integrációt és a tesztelést, lehetővé teszi a független üzembe helyezést, és lehetővé teszi az elsődleges belső fejlesztői platform csapatán kívüli fejlesztők számára a szolgáltatók közreműködését és kezelését. Ez olyan nagy vagy megosztott szervezeteknél fontos, ahol nem minden eszközt, szolgáltatást vagy platformot kezelnek központilag, de a szélesebb szervezet továbbra is meg szeretné osztani a képességeket. Szóval, még ha nem is haladsz végig ezen az úton kezdetben, ez valami, hogy gondolni hosszú távon.

Általános tulajdonságok

Minden entitásnak rendelkeznie kell közös tulajdonságokkal, hogy az alapítvány felügyelhesse őket. Néhány megfontolandó tulajdonság:

• Egyedi azonosító
• Name (Név)
• Feladó szolgáltató
• Választható társítások a következőhöz:
  • Tulajdonos felhasználó
  • Tulajdonos csapat
  • Egyéb entitások

A felhasználó és a csapat tulajdonságai három okból fontosak: szerepköralapú hozzáférés-vezérlés (RBAC), felderítés és adatösszesítés (például csapatszintű összefoglalók). Az RBAC-ben való fejlesztés a kezdetektől fogva kritikus fontosságú a biztonság szempontjából, és idővel növekszik a belső fejlesztői platform. Mivel a fejlesztés egy csapat sport, felfedezve, hogy kivel kell beszélni egy entitás gyorsan válik kritikus fontosságú az újrafelhasználás, támogatás, és innersourcing.

Általános és szolgáltatóspecifikus entitások

Emellett olyan általános, magas szintű normalizált entitásokat is létre kell hoznia, amelyeket több szolgáltató is ki tud állítani. Példa:

• Környezetek
• További források
• API-k
• Adattárak
• Összetevők
• Eszközök

Ezeknek általában magas szinten kell lenniük, mint a C4 modellkörnyezetben vagy a legtöbb magas szintű összetevődiagramban . Egy környezet esetében például nem kell megadnia a belső infrastruktúra topográfiájának részleteit: elég információra van szüksége ahhoz, hogy több szolgáltató különböző fogalmi környezeteit listázhassa és társíthassa ugyanabban a felhasználói felületen. Az entitás a rendszeren kívül alacsonyabb részletességi szintekre mutathat ahelyett, hogy mindent fel szeretne használni. Ezek kiindulópontként szolgálnak a felderítéshez, amelyek központi szerepet játszik az adatösszesítés időbeli engedélyezésében.

Mások egy adott használati esetre vagy szolgáltatóra vonatkoznak, ezért érdemes átgondolni, hogyan lehet idővel egyre több entitástípust kezelni.

Sablonok

Ebben a kontextusban a sablon fogalma eltér az entitások azon elképzelésétől, hogy egy művelet végrehajtására szolgálnak. Példaforgatókönyvek például az infrastruktúra kiépítésére, egy adattár létrehozására és más hosszú ideig futó folyamatokra. Ezeknek a sablonoknak bővíthető fejlesztői platformszolgáltatókon keresztül is elérhetőnek kell lenniük, és ugyanazokat a közös tulajdonságokat kell támogatniuk, mint az entitások – beleértve az entitástársításokat is.

A művelet végrehajtásához szükséges bemeneteket is meghatározhatják, akár a rendszer, akár a felhasználó van megadva. Ezek az erőforrások elnevezésétől a választható kiegészítésekig terjedhetnek.

Példák a sablonokra:

• IaC-sablonok
• Alkalmazássablonok (start right) vagy sablontárak
• Folyamat/ munkafolyamat-sablonok létrehozása
• Üzembehelyezési folyamat/ munkafolyamat-sablonok
• Paraméteres szkriptek
• Paraméteres Power Automate-folyamatok (például HTTP-kérés által aktivált felhőfolyamat)
• E-mail-sablonok

Az entitásokhoz hasonlóan a sablonok szolgáltatóspecifikus tulajdonságokat is tartalmazhatnak.

Előfordulhat, hogy minden sablon más-más módon ábrázolja a szolgáltatót. Ezek a Terraform- vagy ARM-sablonoktól a Helm-diagramokig, a paraméteres GitHub Actions munkafolyamatokig vagy az Azure Pipelinesig, az egyszerű szkriptektől és az egyéni formátumoktól terjedhetnek.

A mögöttes sablon tényleges részleteit nem feltétlenül kell központilag tárolni. Ezek különböző adattárakban, adatbázisokban vagy katalógusokban létezhetnek. Használhatja például a GitHub-sablontárakat az alkalmazássablonokhoz, míg az IaC-sablonok egy korlátozott katalógustárban is létezhetnek, amelyhez a fejlesztők csak közvetetten férhetnek hozzá az Azure-beli üzembehelyezési környezetekhez hasonló módon. Más IaC-sablonok tárolhatók egy OCI Artifact Registryben, például Helm-diagramokban. Más esetekben a sablon egy paraméteres HTTP-végpontra mutató hivatkozás lehet. A fejlesztői platformszolgáltatónak elegendő információt kell biztosítania az egyes sablontípusokról, hogy hivatkozni lehessen rájuk, valamint a felhasználói élményben való használathoz elérhető lehetőségeket. Maguk a sablonok azonban a legtermedelemesebb helyen is elhelyezhetők a használati esetekhez.

Egy adott területen dolgozó platformmérnökök vagy szakértők megírhatják ezeket a sablonokat, majd megoszthatják őket a fejlesztői csapatokkal újbóli használat céljából. A sablonok rendszeren keresztüli használatának központosítása lehetővé teszi a fejlesztők önkiszolgáló működését, és olyan védőkorlátokat hoz létre, amelyek segítenek a szervezeti szabványoknak vagy szabályzatoknak való megfelelés kikényszerítésében. Erről bővebben a fejlesztői platform vezénylőjét tárgyaljuk egy kicsit.

A fejlesztői platform grafikonja

A fejlesztőiplatform-gráfokra úgy gondolhat, mintha lehetővé teszi, hogy több szolgáltató entitásait és sablonjait egy kereshető gráfhoz társítsa. Az entitások tényleges adatait azonban nem feltétlenül kell közvetlenül egy gráfspecifikus adatbázisban megőrznünk. Ehelyett a szolgáltatókkal folytatott interakciók gyorsítótárazhatók a szükséges metaadatokkal együtt, hogy az összeférjen.

A gráf akkor hatékony, ha olyan közös entitásokkal használja, amelyekhez több szolgáltató is hozzájárulhat. Előfordulhat például, hogy az API-k listája egy olyan termékből származik, mint az Azure API Center, de érdemes lehet automatikusan betáplálást végezni az üzemelő példányokban és környezetekben a folyamatos üzembe helyezési rendszerekből. Idővel válthat a különböző központi telepítési rendszerek között, vagy akár több központi telepítési rendszert is támogathat. Mindaddig, amíg minden központi telepítési rendszer rendelkezik fejlesztői platformszolgáltatóval, továbbra is képesnek kell lennie a társításra.

A gráfból létrehozott felhasználói élmények ezután kihasználhatják a gyakori API-k előnyeit az energiafelderítés, a keresés, a szabályozás és egyebek terén. A fejlesztői platform vezénylője ezt a gráfot használhatja, így a fejlesztői platformszolgáltató által végrehajtott műveletek automatikusan hozzájárulnak az ugyanahhoz az API-hoz elérhető entitásokhoz.

Fejlesztői platform vezénylője

A fejlesztői platform vezénylője lehetővé teszi a fejlesztők vagy rendszerek számára, hogy kéréseket hozzanak létre egy művelet sablonnal történő végrehajtásához. Nem maga hajtja végre ezeket a műveleteket, hanem egy feladatmotorral, munkafolyamat-motorral vagy más vezénylővel koordinálja ezt. Ez az egyik kritikus elem, amelyet biztos szeretne lenni abban, hogy része az önkiszolgáló alaprendszernek. Lehetővé teszi a fejlesztők számára, hogy sablonnal hozzanak létre kéréseket, vagy közvetlen engedély nélkül hajtsanak végre egy műveletet. Emellett a CI vagy CD fogalmától eltérően ezeknek a műveleteknek nem kell az alkalmazás forráskódjához kapcsolódnia.

A szoftvermérnöki rendszerek alkalmazásával kapcsolatos szakaszban leírtak szerint vezénylőként használhatja a GitHub Actions, az Azure Pipelines vagy egy másik munkafolyamat-motort. Ez egy ésszerű kezdési hely, de érdemes lehet némi absztrakciót alkalmazni, hogy a különböző sablontípusok különböző mögöttes motorokat használhassanak. Ez több okból is hasznos lehet:

• Először is valószínűleg képes lesz különböző munkafolyamat- és feladatvégrehajtási motorokat választani az idő múlásával anélkül, hogy villognia kellene. Ha egynél több motort engedélyez, idővel migrálhat, vagy egyszerűen használhatja az új motort az új műveletekhez anélkül, hogy ez hatással lenne a régebbiekre.
• A vezénylésben segíteni kívánt folyamatok némelyike manuális lépéseket igényelhet, még akkor is, ha később teljesen automatizálni szeretné őket.
• Más műveletek a fejlesztői csapaton kívüli szerepköröket célozhatják meg, például a fizetendő fiókokat vagy a licencrendszergazdát. Az alacsony kódú motorok, például a Power Automate gyakran jól működnek ezekhez a szerepkörökhöz.
• Más műveletek is kezelhetők egyszerű HTTP-kérésekkel, ahol a GitHub Actions vagy az Azure Pipelines nem szükséges vagy költséghatékony a skálázáshoz.

Szerencsére a szükséges absztrakciót a fejlesztői platform szolgáltatójának az aktiválási és követési automatizálási lépésekre való kiterjesztése biztosítja. Tekintse meg az alábbi ábrát:

Az általános koncepció a következő:

1. A sablonok opcionálisan megadhatnak egy bemeneti halmazt, amelyet a felhasználó megadhat. Amikor egy fejlesztő elindít egy adott műveletet, kiválaszt egy sablont (még akkor is, ha nem így írta le), és bármilyen bemenetet megad.
2. A sablonnal kapcsolatos bemenetekre való hivatkozás kéréssé válik a fejlesztői platform API-ban.
3. A kérés elküldése után a kérések útválasztási és kezelési összetevője a vezénylőn belül megkezdi a kérelem életciklusának nyomon követését. A kérelem útválasztási és kezelési összetevő-útvonalsablonja a kérelemben annak a fejlesztői platformszolgáltatónak, ahonnan a sablon származik.
4. A fejlesztői platformszolgáltató ezután végrehajtja a megvalósításhoz szükséges lépéseket.
5. [Nem kötelező] A fejlesztői platform szolgáltatója a művelet végrehajtásakor frissíti a kérés állapotát.
6. A kérés teljesítését követően a fejlesztői platformszolgáltató visszaadhatja a fejlesztői platform gráfjában hozzáadandó/frissítendő entitások egy készletét. Ezek lehetnek szolgáltatóspecifikus vagy közös entitások.

A speciálisabb interakciók támogatása érdekében engedélyezheti, hogy ezek a fejlesztői platformszolgáltatók közvetlenül meghívják a fejlesztői platform API-t, hogy több entitást kérjenek bemenetként, vagy akár egy másik kapcsolódó műveletet kérjenek.

Bár az ön által kiértékelt megoldás vagy termék eltérő lehet, ez a tulajdonságokat is érzékelteti.

Ezt szem előtt tartva olyan fejlesztői platformszolgáltatót szeretne használni, amely egy általános feladatot vagy munkafolyamat-motort használ. Pontosabban azt szeretné, hogy valami áthidalja a szoftvermérnöki rendszerek alkalmazásának részeként összeállított elemeket. Az egyik általános munkafolyamat- vagy feladatvégrehajtási motor, amelybe valószínűleg befektetni fog, a CI/CD-rendszer.

Példa a GitHub Actions vagy az Azure Pipelines használatára

Röviden nézzük meg, hogyan működne egy GitHub Actions vagy az Azure Pipelines fejlesztői platformszolgáltatóként.

A GitHub Actions esetében ennek a munkának az a kulcsa, hogy egy fejlesztői platformszolgáltató csatlakozhat a megadott GitHub-példányhoz, és az Actions REST API használatával elindíthat egy munkafolyamat-küldési eseményt a munkafolyamat-futtatás elindításához. Minden munkafolyamat támogatja a bemenetek készletét, ha hozzáad egy workflow_dispatch konfigurációt a munkafolyamat YAML-fájlhoz. Az Azure DevOps-eseményindítók hasonlóak, és az Azure DevOps Pipeline API-t is használhatja a futtatásokhoz. Valószínűleg ugyanazokat a képességeket fogja látni más termékekben is.

Ezeknek a munkafolyamatoknak/folyamatoknak nem kell az alkalmazás forráskód-adattáraiban lenniük. A koncepció az lenne, hogy kihasználja ezt a tényt, hogy valami ilyesmi:

1. A platformmérnökök vagy a DevOps-csapat tagjai fenntarthatják a munkafolyamatokat/folyamatokat egy vagy több olyan központi adattárban, amelyhez maguk a fejlesztők nem férnek hozzá, de a fejlesztői platformszolgáltató úgy van beállítva, hogy használja őket. Ugyanez az adattár tartalmazhat szkripteket és IaC-kódrészleteket, amelyeket a munkafolyamatok/folyamatok használnak.
2. Ha lehetővé szeretné tenni, hogy ezek a munkafolyamatok/folyamatok a megfelelő alsóbb rétegbeli rendszerrel kommunikáljanak, a platformmérnöki csapat műveleti vagy más tagjai hozzáadhatják a szükséges titkos kulcsokat a központi adattárhoz. Ennek módjáról a GitHub Actions és az Azure DevOps dokumentációjában olvashat, vagy dönthet úgy, hogy az Azure Key Vault használatával központosítja a titkos kulcsokat.
3. Ezek a munkafolyamatok/folyamatok ezután követhetnek egy modellt, amelyben az eredményül kapott entitásokat buildelési/üzembehelyezési összetevőként teszik közzé (GitHub-dokumentumok, Azure DevOps-dokumentumok).
4. A futtatás során a fejlesztői platform szolgáltatója ezután watch a munkafolyamat/folyamat állapotát, és frissítheti az életciklus állapotát a vezénylőben, amíg az befejeződik. A frissítések nyomon követéséhez használhat például webhookokat GitHub Actions és szolgáltatáshookokat az Azure Pipelines használatával.
5. Miután elkészült, a szolgáltató felhasználhatja a közzétett összetevőt, hogy szükség szerint bekerüljön a fejlesztői platform grafikonjára.

Végül beállíthatja ezt a fejlesztői platformszolgáltatót, hogy sablonkészletet adjon ki a fejlesztői platform grafikonjára, amely a megfelelő adattárra és munkafolyamatra/ folyamatra hivatkozik, valamint egy adott feladat bemeneteit.

A CI/CD-rendszer használatához az a nagy dolog, hogy gyakran úgy vannak beállítva, hogy támogatják az tetszőleges CLI-k futtatását, így nincs szükség első osztályú, egyedi integrációra mindenhez, amit csinál. Ezeket igény szerint hozzáadhatja.

Az ebben a példában ismertetettek nagy része arra vonatkozik, hogy más típusú szolgáltatók hogyan működhetnek. Azt is fontos megjegyezni, hogy a GitHub Actions vagy az Azure Pipelines ebben a környezetben való használatához nincs szükség arra, hogy azokat a tényleges CI/CD-folyamatokhoz is használja.

Egyéb példák

Íme néhány példa más típusú fejlesztői platformszolgáltatókra, amelyek sablonokat dolgozhatnak fel.

Bár előfordulhat, hogy nincs szüksége ezekre a szolgáltatókra a kezdéshez, láthatja, hogy a fejlesztői platformszolgáltatóhoz hasonló bővíthetőség hogyan segítheti az automatizálási képességek időbeli növekedését.

Felhasználók és csapatok

A platformfejlesztés eredendően többrendszeres ügy, ezért fontos megtervezni, hogy egy önkiszolgáló alaprendszer hogyan kezelje az e rendszerek integrálásával kapcsolatos, kihívást jelentő problémákat. Ebben a szakaszban egy stratégiát ismertetünk az identitással, a felhasználókkal és a csapatokkal kapcsolatos gyakori kihívások kezelésére.

Először is fontolja meg ezt a két javaslatot:

A következő lépésben ezekből a javaslatokból fogunk felépíteni egy modellt, amely a nagyobb kihívást jelentő problémákat kezeli ezen a területen.

A csapat fogalmának létrehozása egyetlen identitásszolgáltatói csoporton kívül

Ahogy a platformtervezési folyamat folytatódik, valószínűleg azt fogja tapasztalni, hogy az identitásszolgáltatói csoportok kiválóan alkalmasak a tagság kezelésére, de több csoportnak is össze kell fognia ahhoz, hogy a szerepköralapú hozzáférés-vezérlést (RBAC) és az adatösszesítést használó csapat fogalmát alakítsa ki.

A platformfejlesztés kontextusában a csapatokat különböző szerepkörökben dolgozó személyek csoportjáként definiáljuk, akik együtt dolgoznak. Az adatösszesítések esetében a többszerepű csapat ötlete kritikus fontosságú a felderítés és az információk összesítése szempontjából olyan helyeken, mint a jelentéskészítési irányítópultok. Másrészt a csoport egy általános identitásszolgáltatói koncepció a felhasználók egy csoportjához, és úgy lett kialakítva, hogy több embert adjon hozzá egy adott szerepkörhöz, nem pedig fordítva. Az RBAC-vel a csapatok ezért különböző szerepkörökkel kapcsolódhatnak több identitásszolgáltatói csoporthoz.

A csapatadatok forrása néhány különböző helyről származhat. Ha például kódmintaként (TaC) használja a teamst, a fejlesztői platform szolgáltatója watch az adattárak fájlmódosításaihoz, és gyorsítótárazhatja őket egy felhasználói profilban és a csapat metaadatainak tárolójában. Vagy közvetlenül integrálhat olyan Azure Dev Center-projekttel , amely már rendelkezik ezekkel az alapvető RBAC-szerkezetekkel.

Modell létrehozása az alsóbb rétegbeli rendszerekkel való integráláshoz a csapat vagy a felhasználó szintjén

Míg egyes fejlesztői és üzemeltetési eszközök/szolgáltatások natív módon integrálják és közvetlenül használják az identitásszolgáltatói fogalmakat, sokan ezt egy csoport vagy felhasználó saját reprezentációjába (akár egyszeri bejelentkezéssel is) absztrakcióra használják. Az eszközök közötti hozzáférés engedélyezésén túl ez a valóság az adatösszesítéssel kapcsolatos problémákat is okozhat. Pontosabban azt tapasztalhatja, hogy az alsóbb rétegbeli rendszerek API-jai az identitásszolgáltatói azonosítók helyett saját azonosítókat használnak (például: az Entra-azonosító objektumazonosítóját nem használja közvetlenül). Ez megnehezíti a felhasználói vagy csoportszintű adatok szűrését és társítását, hacsak nem tud különböző azonosítók közötti leképezést elvégezni.

Csoport- és csoportszintű különbségek kezelése

A TaC-hez hasonló minták lehetővé teszik az egyes rendszerek csapat- vagy csoportazonosítói közötti kapcsolatok tárolását és elérését, hogy ezek között megfeleltethető legyen. Összefoglalva, egy biztonságos, naplózható Git-adattár válik egy csapat forrásává, a PRS pedig egy ellenőrzött felhasználói felületet biztosít a frissítések készítéséhez. A CI/CD-rendszerek ezután frissíthetik az alsóbb rétegbeli rendszereket, és megőrizhetik az ehhez használt csapat azonosító kapcsolatait.

Ez például lehetővé teszi a következő kapcsolatok tárolását API-hívásokban:

Ha a csapatok adattárában lévő fájloktól eltérő adatforrást szeretne használni, ugyanezt az általános koncepciót alkalmazhatja a fejlesztői platform vezénylőjének használatával is. Ebben a modellben a csapatadatok forrásának fejlesztői platformszolgáltatója elindíthat egy csapatfrissítési eseményt, amelyet minden más szolgáltató megkap és a megfelelő módon hajt végre.

A felhasználói azonosítóval kapcsolatos kihívások kezelése

Az adathozzáférés és az összesítés egy másik kapcsolódó kihívása a felhasználói azonosítók eltérései. A csapatesethez hasonlóan, ha rendszerközi integrációt használ egy felhasználó adatainak lekérdezéséhez, nem feltételezheti, hogy az identitásszolgáltatók natív azonosítója (például az Entra-azonosító objektumazonosítója) támogatja az adott API-t. Itt is segíthet egy olyan felhasználói azonosító leképezésének tárolása, amely a fejlesztői platform API-ján keresztül fér hozzá az adatokhoz. Vegyük például a GitHubot:

Minden rendszer esetében, ha egy felhasználóazonosító egy másik rendszer keresésére képes egy felhasználói jogkivonat nélküli API-n keresztül, egy adott fejlesztői platformszolgáltató menet közben létrehozhatja ezt a leképezést. Bizonyos esetekben ez bonyolulttá válhat, mivel előfordulhat, hogy tömegesen kell végrehajtania ezt a műveletet, és gyorsítótárazza az eredményeket a teljesítmény fenntartása érdekében.

Visszalépés több felhasználói jogkivonat használatával

Azokban az esetekben, amikor a szolgáltatóknak felhasználói szintű adatokhoz kell hozzáférnie anélkül, hogy a felhasználói azonosítók fordítása működne, a fejlesztői platform API-ja több felhasználói jogkivonat kezelésére is beállítható. Példa:

1. A fejlesztői platform API támogatja a szolgáltatóspecifikus felhasználói jogkivonatok gyorsítótárát az alsóbb rétegbeli rendszerekkel való használathoz.
2. Az API által aktivált, adott szolgáltatóval folytatott interakciók a szolgáltató felhasználói jogkivonatában is szerepelnek, ha vannak ilyenek.
3. Ha kezelni szeretné azt az esetet, amikor nem volt elérhető felhasználói jogkivonat, a szolgáltató egy OAuth-folyamatot aktiválna egy lekéréshez.
4. Első lépésként a fejlesztői platform API egy OAuth-folyamat hitelesítési URI-jét adja vissza a szolgáltatónak átadott átirányítási URI-val. A megadott URI egy nem egyszeri használatú kódot tartalmazna.
5. Az API ezután egy "nem hitelesített" választ ad vissza az URI-val.
6. Ezután bármely felhasználói felület ezt az URI-t használhatja a megfelelő hitelesítési folyamat egy böngészőben való irányításához.
7. Miután megtörtént az átirányítás, a fejlesztői platform megkapja a szükséges felhasználói jogkivonatot, és gyorsítótárazza a jövőbeli referenciaként a felhasználói azonosítóval együtt.
8. Az ügyfél ezután újra megpróbálhatja az API-hívást, ami sikeres lesz.

Ez a koncepció a bonyolult hitelesítés kezelésének módját vázolja fel, mivel lehetőség szerint újra felhasználhatja az azonosítókat, és nem kell külön átirányítási URI-kat fenntartania alsóbb rétegbeli rendszerekenként.

Adatok összesítése és további képességek biztosítása

Környezettudatos mélyhivatkozások használata eszközökhöz és jelentéskészítő rendszerekhez

Eddig a pontig a problématér automatizálási aspektusáról beszéltünk. Ez önmagában is hosszú utat vehet igénybe, mivel a felhasználói felület az automatizálás során visszaadott entitásokban lévő értékekkel mély kapcsolatokat hozhat létre a csapat más rendszereibe.

A fejlesztői platformszolgáltatók akkor is kibocsáthatnak bármilyen entitásra vonatkozó igényt, ha nem automatizálással kapcsolatosak. Általában azonban nem szeretné az összes részletes adatot a teljes belső fejlesztői platformon a fejlesztői platform gráfjába behozni. Az olyan megfigyelhető megoldások irányítópultjai, mint a Grafana, a Prometheus, a DataDog vagy a kódintelligencia az olyan termékekben, mint a SonarQube, és a DevOps-csomagok natív képességei, mint a GitHub és az Azure DevOps, mind nagyon alkalmasak. Ehelyett a legjobb módszer gyakran mély kapcsolatok létrehozása ezekbe a más rendszerekbe. Az entitások elegendő információt nyújthatnak a hivatkozások létrehozásához anélkül, hogy közvetlenül tartalmaznék a részletes információkat, például a napló tartalmát.

Azokban az esetekben, amikor összesített és összesített adatokat szeretne az eszközök között, vagy egyéni metrikákat kell vezetnie, a Power BI vagy a Microsoft Fabric jelentéskészítési megoldások lehetnek a következő hívási portok. A csapatadatok egyesítéséhez kapcsolódhat az alapítvány adatbázisához, vagy egy fejlesztői platform API-ján keresztül. Például a Tervezés és rangsorolás szakaszban leírtak szerint az egyik hely, ahol egyéni irányítópultra lehet szüksége, a belső fejlesztői platform sikerességét méri.

Legyen szelektív minden egyes extra felülettel, amit létrehoz

Bár vonzó lehet a meglévő képességek újbóli létrehozása egy közös portálon, ne feledje, hogy azt is fenn kell tartania. Ez az a terület, ahol fontos a termék szemléletének követése. Az irányítópult-stílusú felületek könnyen értelmezhetők és könnyen értelmezhetők, de a fejlesztők máshol több értéket találhatnak.

Ez azt jelenti, hogy az itt található modell lehetővé teszi, hogy összesített adatokat használjon a fejlesztői platform grafikonjában egyéni felhasználói élmények létrehozásához. Az entitásoknak beépített támogatással kell rendelkezniük, hogy egy felhasználóhoz vagy csapathoz kötődhessenek. Ez lehetővé teszi a fejlesztői platform API-nak a kimenet hatókörét (az indexelés és a gyorsítótárazás használata mellett).

Azonban még akkor sem a legjobb módszer, ha egy mély kapcsolat helyett egyéni felhasználói felületet kell létrehoznia, és az összes adatot a fejlesztői platform gráfjába kell behúzni. Vegyük például azt a helyzetet, amikor érdemes lehet olyan naplókat megjeleníteni a felhasználói felületen, amelyeknek már van egy jól definiált és felügyelt otthona. A kapcsolódó entitásokban található információk segítségével a felhasználói felület közvetlenül az alsóbb rétegbeli rendszerekből gyűjthet információkat.

Első lépésként előfordulhat, hogy rendszer-rendszer integrációt kell használnia a csatlakozáshoz, de miután implementálta a felhasználókban és a csapatokban leírt modellek egyikét, szükség esetén használhatja a tárolt alsóbb rétegbeli felhasználó-/csapatazonosítókat vagy felhasználói hitelesítési jogkivonatokat.

Íme néhány példa a gyakori tapasztalatokra, amelyeket érdemes megfontolni:

Felhasználói élmények

A szervezet különböző szerepkörei olyan eszközökkel vagy szolgáltatásokkal rendelkeznek, amelyek a mindennapi munkájuk súlypontját képviselik. Ezeknek a rendszereknek a húzása megnehezítheti az új felhasználói élmények számára ezen gravitációs központokon kívül a vontatást. A tökéletes világban a fejlesztők, a műveletek és más szerepkörök továbbra is dolgozhatnak olyan környezetben, amely értelmes számukra – gyakran azokat, amelyeket már használnak.

Ezt szem előtt tartva jó ötlet, ha több felhasználói felületet tervez a platform mérnöki folyamatának előrehaladása során. Ez lehetőséget nyújt arra is, hogy egyszerű, értékeket bizonyító és egyre összetettebb felületek felé haladjon, amikor szükség van rá.

A meglévők integrálása

Ha elolvasta a Szoftvermérnöki rendszerek alkalmazása és az Alkalmazásplatform finomítása című cikkeket, valószínűleg azonosította a használni kívánt rendszereket. Mindkét esetben értékelje ki, hogy bővítheti-e és bővítheti-e azt, amije van, mielőtt elkezdené az új élményeket az alapoktól kezdve létrehozni. (Kérdezd meg magadtól, hogy az emberek jobban reagálnak-e egy másik új felhasználói felületre vagy egy továbbfejlesztett verzióra, amit most már használnak?)

A tovább használni kívánt eszközök, segédprogramok vagy webalkalmazások némelyike egyéni lesz, és ezek jó választásnak számítanak a fejlesztéshez. Ne felejtse el azonban figyelni, hogy kedvenc eszközei és szolgáltatásai rendelkeznek-e bővíthetőségi modellel. Sok előnyre lesz szüksége az ott való kezdéshez. Ezzel kiküszöbölheti a karbantartási és biztonsági problémákat, és a megoldandó problémára összpontosíthat

Például kiterjesztheti a már használt alábbi felületeket:

• Szerkesztők és azonosítók.
• A DevOps-csomagod.
• A CLI-k is egyre bővíthetőbbek.
• Alacsony/kód nélküli környezetek, például a Power Pages.

Mindegyik jobb kiindulási pontot biztosíthat egy adott szerepkörhöz, mint amit az alapoktól állít be, mivel ezek már létező gravitációs központok. Ha alapkonfigurációként rendelkezik egy közös fejlesztői platform API-val, azzal idővel felcserélheti a dolgokat, kísérletezhet és módosíthatja azokat.

A fejlesztői portál létrehozásához fontolja meg a webszerkesztő bővítményeinek használatát

Ha webes felületet keres a fejlesztőknek, vegye figyelembe, hogy a szerkesztők és ides webes verziói a legújabb trendek. A VS Code-ot használó felhasználókhoz hasonlóan sokan rendelkeznek bővítménytámogatással. A VS Code-tal minden, amit ezekhez a webes élményekhez készít, majd helyben fordítja le a két előnyt.

Az olyan szolgáltatásokon kívül, mint a GitHub Codespaces, vscode.dev a VS Code-szerkesztő ingyenes webes verziója, számítás nélkül, de bizonyos típusú bővítmények támogatását is magában foglalja, beleértve azokat is, amelyek webnézeteket használnak az egyéni felhasználói felülethez.

Még ha a fejlesztők nem is használják magát a VS Code-ot, az UX-minták jól ismertek, és más fejlesztői eszközökben is megtalálhatók. A vscode.dev használata kényelmes és ismerős webalapú alapot nyújthat a fejlesztői élményhez az eszköz mellett.

Ezek a fejlesztőkre összpontosító portálként működhetnek ismerős formában, amely helyi használatra is lefordítható.

ChatOps

Egy másik lehetőség, amelyet gyakran figyelmen kívül hagynak, egy ChatOps-felület implementálása. Mivel az AI-termékek, például a ChatGPT és a GitHub Copilot növekedése miatt nő a csevegésalapú felületek száma, a műveletparancsok vagy perjelparancsok hasznos módot nyújthatnak az automatizálási munkafolyamatok indítására, az állapot ellenőrzésére és egyebekre. Mivel a legtöbb alkalmazás CI/CD-platform támogatja az olyan rendszerek használatát, mint a Microsoft Teams, a Slack vagy a Discord, ez természetes módja annak, hogy integrálható egy másik felhasználói felület fejlesztőivel és a kapcsolódó üzemeltetési szerepkörökkel, amelyeket naponta használnak. Ezen kívül mindegyik termék bővíthetőségi modellel rendelkezik.

Befektetés egy új fejlesztői portálba

Feltéve, hogy nem rendelkezik meglévő portállal vagy felülettel, amelyet alapként szeretne használni, dönthet úgy, hogy létrehoz egy új fejlesztői portált. Gondoljon erre úgy, mint egy célhelyre, nem pedig kiindulópontként. Ha még nem rendelkezik önnel fejlesztőcsapattal, ennek megkezdéséhez itt az ideje. Minden szervezet más, ezért nincs egy méret-all-all válasz arra, hogy mi legyen az ilyen típusú élményben. Ennek eredményeképpen nincs defacto válasz egy előre csomagolt termékre, amelyet fel lehet pörgetni, és használhatja az is-t valami ilyesmire ma.

A saját üzemeltetésű egyéni beállítások esetében az általános webportál-keretrendszerek nem újak, és előfordulhat, hogy a fejlesztői csapatok már olyant használnak, amelybe koppinthat. Ha a felhasználók előtt próbál kivenni valamit a korai visszajelzések érdekében, akár egy olyan egyszerű dologgal is kezdhet, mint az alacsony kódú Power Pages , hogy csatlakozzon a közös fejlesztői platform API-hoz.

A fejlesztői portálra irányuló újabb erőfeszítések nagyobb véleményeket adnak. Például a Backstage.io egy egyéni fejlesztői portál eszközkészlete, amelyet eredetileg a Spotify igényeinek megfelelően készítettek. Tartalmaz egy cli-t, amely segít a forrásfának a create-react-apphoz hasonlóan React.js történő rendszerindításában.

A portál eszközkészleteként munkát igényel a kezdéshez, a testreszabáshoz pedig a TypeScript, a Node.js és a React ismerete szükséges. A nagy dolog azonban az, hogy eszközkészletként szinte bármit megváltoztathat. Rendelkezik saját szoftverkatalógussal és templating mechanizmussal is, de a használatuk nem szükséges, és jól meghatározott módon hozhat létre új, 1^st és 3^rd féltől származó, beépülő modulnak nevezett kódot.