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

Ha már jól ismeri a mérnöki rendszerekre vonatkozó célokat, kifinomultabb fejlesztői önkiszolgáló szolgáltatásokat hozhat létre. A fejlesztői önkiszolgáló élmény fogalmak, minták és összetevők alapjaira épül.

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. A fejlesztői önkiszolgáló élménymodell az otthoni, a polcon kívüli és a nyílt forráskódú termékek kombinációjából áll. Előfordulhat, hogy a termékek vagy a nyílt forráskódú portál eszközkészletei, például Backstage.io különböző kifejezéseket használnak az itt ismertetett modell egyes elemeihez, de a modell továbbra is segíthet a tájékozódásban.

Munkafolyamatok automatizálása, adatok összesítése, egyszerű indítás és fokozatos kibontás

A cél az önkiszolgáló rendszer biztosítása védőkorlátokkal ellátott, szabályozott feladatvégrehajtással és ellátással, valamint a központosított átláthatóság megteremtése. Azokra a területekre kell a legértékesebben összpontosítani, amelyek vagy unalmasak, vagy olyan dolgok, amelyekre a fejlesztő nem képes az összetettség vagy az engedélyek miatt. Ez az utolsó elem fontos, mert lehetővé teszi, hogy kövesse a legkisebb jogosultság elvét úgy, hogy közben a fejlesztőket nem kell manuális ügyfélszolgálati folyamatra kényszeríteni.

Bár dönthet úgy, hogy kibővíti a DevOps-csomagot ezeknek az igényeknek megfelelően, 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ányaid mozgó célpontot jelentenek. Ahogy az egyik platformmérnök elmondta:

A nehézségek magukban foglalják a szabványosítást ... és az "abandonware" kezelése... A szabványosítást gyakran nem sikerül elérni az automatizált folyamatok lehetséges 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, nagy logisztikai vállalat

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ő különböző eszközöket és fejlesztői szolgáltatásokat használ forgatókönyvek szerint. Még egy központi csapattal és egy standard megoldással is, mivel az önkiszolgáló szolgáltatásnak növekednie kell, a variabilitás elkerülhetetlen. Ezért engedélyeznie kell az ellenőrzött kísérletezést, ahol a kijelölt csapatok kipróbálhatják az új technológiákat, az üzembe helyezési stratégiákat stb., majd a szándékos bevezetést és a növekményes bevezetést.

Az önkiszolgáló szolgáltatások általában két elsődleges kategóriába sorolhatók: az automatizálás és az adatösszesítés.

Bár az adatösszesítés jó felhasználói élményt biztosít, az automatizálás fontosabb:

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

A platformfejlesztés során azonosította az automatizálás által esetleg megoldott problémákat. A kognitív terhelés és a fejlesztői terhelés csökkentése mellett az automatizálás is segíthet biztosítani, hogy az alkalmazások a legjobb üzemeltetési, biztonsági és egyéb szerepkörökhöz csatlakozva végezhessék munkájukat.

Ha azonban egynél 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. Első lépésként külső rendszerekre hivatkozva más igényeknek is megfelelhet, vagy részletezheti 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 a nem használt környezetekben).

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

Első lépésként használja újra a meglévő beruházásokat, például a mérnöki rendszereket vagy egy belső portált, majd váltson 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ára, és igény szerint bontsa ki a műveletet. Ha egy konzisztens API-t használ az UX, az idővel több felületet is támogat, ahogy az igényei és a beállításai változnak.

Fejlesztői önkiszolgáló platformösszetevők: API, graph, vezénylő, szolgáltatók és metaadatok

Fontolja meg a fejlesztői önkiszolgálóság alapjait:

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

Összetevő	Description
Fejlesztői platform API	A felhasználói élmény egyetlen kapcsolattartó pontja. Ez tulajdonképpen a rendszer szerződése más rendszerekkel.
Fejlesztői platform grafikonja	Felügyelt és biztonságos adatgráf, amely lehetővé teszi különböző típusú entitások és sablonok felderítését, társítását és használatát. Az entitások olyan objektumok, amelyek több forrásból származó adatösszesítést tesznek lehetővé, míg a sablonok az automatizálást lehetővé tevő felhasználói bemeneteket hajtják.
Fejlesztői platform kezelője	Olyan képesség, amely sablonalapú kéréseket irányít és követ nyomon, hogy műveleteket hajtson végre egy rendszerben vagy egy manuális folyamaton keresztül. Ezek a kérések olyan fejlesztői platformszolgáltatók egyikéhez vannak átirányítva, amelyek bármilyen számú munkafolyamat-rendszerbe vagy más szolgáltatásba integrálhatók.
Fejlesztői platformszolgáltatók	Olyan összetevők készlete, amelyek logikát foglalnak össze az alárendelt rendszerekkel való integrációhoz az entitásokon végzett CRUD-műveletek támogatásához vagy a sablonalapú műveleti kérések teljesítéséhez. Minden szolgáltató támogathatja a saját adott sablontípusát, és egyedi vagy gyakori entitástípusokat bocsáthat ki.
Felhasználói profil és csapat metaadatai	A fejlesztői platform API-hoz való csoportosításhoz és hozzáféréshez egy elméleti csapathoz kötődő egyénekről szóló információk megőrzésének képessége. A felhasználó szorosan kapcsolódik egy identitásszolgáltatói fiókhoz (például Microsoft Entra ID-bejelentkezéshez), de mind a felhasználó, mind a csapat bármilyen kapcsolódó alárendelt rendszer-ábrázoláshoz kapcsolódhat. Ennek az információs tárnak az egyik implementációja a fejlesztői platform gráfjának újrafelhasználása. A fejlesztői önkiszolgáló alaprendszer közös entitástípust hozhat létre mind a felhasználó, mind a csapat számára, és megőrizheti ezeket az információkat a gráfban. Az átláthatóság érdekében azonban külön fogjuk kezelni ezt az áruházat.

Ezek az alapvető összetevők lehetővé teszik a különböző építőelemek időbeli használatát és cseréjét.

Kell mindezt felépítenem, hogy elkezdhessem?

Nem. Először is ez egy fogalmi modell, amely segít végiggondolni, hogy egy ilyen alap mire lesz képes, ha elkészült. Másodszor, a megvalósítási specifikusságok 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 keveredik. Kihagyhat bizonyos szempontokat is, mert az ügyfélfejlesztés azt jelzi, hogy ez egyszerűen alacsonyabb prioritás. Kezdje azzal, ami van, és növekedjen.

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, a meghajtók kiépítésének és egyéb műveletek engedélyezéséhez.

Ez az API fontos hitelesítési és biztonsági rétegként működik azáltal, hogy a nyers mögöttes API-khoz való hozzáférést más rendszerekben konkrétabb, szabályozott 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ó magas szintű szerepköréhez a platformon belül (csapattag, rendszergazda stb.), valamint 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 olyan rendszereket kell létrehoznia vagy azonosítania, amelyek egy bővíthető szolgáltatói modellt követnek a funkciók API-ba való bevezetéséhez. Az elképzelés 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 csatlakozó segít abban, hogy növekményesen bekötje a szükséges elemeket, és javítja a karbantarthatóságot, mivel az alaptól függetlenül tesztelheti a funkciókat.

Emellett fontos módja annak, hogy a platform skálázható belső forrásként használható mentalitást biztosíthasson. A platformfejlesztéssel kapcsolatos belső forrásbeszerzési erőfeszítések általában nem nyernek vontatást a folyamatos karbantartással járó kihívások miatt. Előfordulhat, hogy más csapatok hajlandóak a funkciókkal is 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 a lekéréses kérelmek áttekintésére. A fejlesztői platformszolgáltató koncepciója enyhíti ezt a feszültséget azáltal, hogy lehetővé teszi az önállóan írt kódnak a fejlesztői önkiszolgáló alaprendszer alapvető funkcióihoz való csatlakoztatását . 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ületet, a csatlakoztatható megközelítés a szervezet nagyobb részének skálázásával segítheti a további munkát.

A fejlesztői platform szolgáltatói alapfogalmai

Entities

Az entitás fogalma olyan dolog, amelyet a belső fejlesztői platform fejlesztőjének vagy más rendszerének nyomon kell követnie, frissítenie, bemutatnia vagy követnie kell. Az entitásoknak lehetnek kapcsolataik egymással, amelyek együttes használata esetén egy olyan gráfot alkotnak, amely kritikus információkat nyújt a belső fejlesztői platform egyes részeiről. A fejlesztőiplatform-szolgá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 rendelkezésre álló API-k felderítése és használata
• Kapcsolatok felfedése függőségelemzéshez, hatáselemzéshez, felderítéshez stb.
• A fenntartók/tulajdonosok információinak megjelenítése a felfedezés és az együttműködés érdekében
• További adatok megismeré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 megosztó szervezetekben fontos, ahol nem minden eszközt, szolgáltatást vagy platformot kezelnek központilag, de a tágabb szervezet továbbra is meg szeretné osztani a képességeket. Tehát, még ha nem is haladsz végig ezen az úton kezdetben, akkor is érdemes hosszú távon átgondolni.

Általános tulajdonságok

Minden entitásnak rendelkeznie kell egy közös tulajdonságokkal, amelyek lehetővé teszik az alap számára, hogy felügyelje őket. Néhány megfontolandó tulajdonság:

• Egyedi azonosító
• Név
• Kezdeményező szolgáltató
• Választható társítások a következőhöz:
  • Tulajdonos felhasználó
  • Tulajdonosi 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 csoportszintű összefoglalók). Az RBAC kezdeti beépítése kritikus fontosságú a biztonság szempontjából, és idővel bővíti a belső fejlesztői platformot. A fejlesztés csapatsport, és az, hogy felfedezzük, kivel érdemes beszélni egy entitásról, gyorsan kritikus fontosságúvá válik az újrafelhasználás, a támogatás és az innersourcing szempontjából.

Gyakori é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 képes kihozni. Például:

• Environments
• Resources
• API-k
• Adattárak
• Components
• Tools

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ótól származó különböző koncepcionális környezeteket listázz és társítsunk ugyanabban az UX-ben. Az entitás külső, a rendszeren kívüli alacsonyabb részletességi szintekre mutathat, ahelyett, hogy megpróbálná az összes részletet feldolgozni. Ezek kiindulópontokat biztosítanak 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 befogadni.

Sablonok

A sablon fogalma ebben a kontextusban eltér az entitások elképzelésétől abban, hogy egy művelet vezetésére szolgálnak. Példaforgatókönyvek például az infrastruktúra kiépítése, az adattár létrehozása és más hosszú ideig futó folyamatok. Ezeknek a sablonoknak bővíthető fejlesztői platformszolgáltatókon keresztül is elérhetővé 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ározhatnak, függetlenül attól, hogy a rendszer vagy a felhasználó van-e megadva. Ezek az erőforrás elnevezésétől az opcionális kiegészítésekig terjedhetnek.

Példák a sablonokra:

• Infrastruktúra kódként (IaC) sablonok
• Alkalmazássablonok (jobbra indítás) vagy sablonkönyvtárak
• Folyamat/ munkafolyamat-sablonok létrehozása
• Üzembehelyezési folyamat / munkafolyamat-sablonok
• Paraméteres szkriptek
• Paraméteres Power Automate-folyamatok (például EGY 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, a szolgáltatóra jellemző megjelenítéssel rendelkezik. Ezek a Terraform- vagy ARM-sablonoktól a Helm-diagramokig, a paraméteres GitHub Actions-munkafolyamatokig vagy az Azure Pipelinesig, az egyszerű szkriptektől vagy az egyéni formátumokig terjedhetnek.

A tényleges mögöttes sablonadatokat nem feltétlenül kell központilag tárolni. Ezek különböző adattárakban, nyilvántartásokban vagy katalógusokban létezhetnek. Használhat például GitHub-sablontárakat az alkalmazássablonokhoz, míg az IaC-sablonok egy korlátozott katalógusadattárban létezhetnek, amelyhez a fejlesztők csak közvetett módon férhetnek hozzá az Azure Deployment Environmentshez hasonló módon. Előfordulhat, hogy más IaC-sablonok egy OCI Artifact Registryben, például Helm-diagramokban vannak tárolva. Más esetekben a sablon egy paraméteres HTTP-végpontra mutató hivatkozás lehet. A fejlesztőiplatform-szolgá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álatra elérhető lehetőségeket. A sablonok azonban elhelyezhetők a használati esetek legtermészetesebb helyén.

Egy adott terület platformmérnökei vagy szakértői sablonokat írnak, majd megosztják őket a fejlesztői csapatokkal újrahasználat céljából. Ezeknek a sablonoknak a rendszeren keresztüli központosítása lehetővé teszi a fejlesztői önkiszolgáló szolgáltatást, és olyan védőkorlátokat hoz létre, amelyek segítenek kikényszeríteni a szervezeti szabványoknak vagy szabályzatoknak való megfelelést. Erről bővebben fogunk beszélni, amikor hamarosan az orchestrátort, a fejlesztői platform irányítóját tárgyaljuk.

Fejlesztői platform grafikonja

A fejlesztői platform gráfjai olyannak tekinthetők, amely 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 őrizni. Ehelyett a szolgáltatókkal folytatott interakciók gyorsítótárazhatók a szükséges metaadatokkal együtt, hogy minden összhangba kerüljön.

A gráf akkor hatékony, ha olyan gyakori entitásokkal használja, amelyekhez több szolgáltató is hozzájárulhat. Az API-k listája például származhat egy olyan termékből, mint az Azure API Center, de hasznos lehet automatikusan betölteni a telepítéseket és környezeti beállításokat 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 a felderí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 ki, így a fejlesztői platformszolgáltató által végrehajtott műveletek automatikusan hozzájárulnak az ugyanazon API-hoz elérhető entitásokhoz.

Fejlesztői platform kezelője

A fejlesztői platform vezénylője lehetővé teszi a fejlesztőknek vagy rendszereknek, hogy kéréseket hozzanak létre egy sablonnal végzett művelet 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 biztosnak kell lennie, hogy része az önkiszolgáló alapítványnak. 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. Ezenkívül a CI vagy a CD fogalmától eltérően ezeknek a műveleteknek nem kell az alkalmazás forráskódhoz kapcsolódnia.

Vezénylőként használhatja a GitHub Actionst, az Azure Pipelinest vagy egy másik munkafolyamat-motort. Ez egy ésszerű kiindulópont, de érdemes lehet egy kis absztrakciót használni, hogy a különböző típusú sablonok különböző mögöttes motorokat használhassanak. Ez néhány okból lehet hasznos:

• Először is érdemes lehet különböző munkafolyamat- és feladatvégrehajtási rendszereket választania idővel anélkül, hogy hirtelen váltania 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.
• Egyes, a vezénylésben segíteni kívánt folyamatokhoz kezdetben manuális lépésekre lehet szükség, 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 licencadminisztrátort. Az olyan alacsony kódszámú motorok, mint a Power Automate, gyakran jól működnek ezekhez a szerepkörökhöz.
• Más műveleteket egyszerű HTTP-kérésekkel is kezelhet, amelyeknél a GitHub Actions vagy az Azure Pipelines nem szükséges vagy költséghatékony a méretezéshez.

Szerencsére a fejlesztői platformszolgáltató ötletének kibővítése az automatizálási lépések aktiválásával és nyomon követésével lehetővé teheti ezt a szükséges absztrakciót. Tekintse meg az alábbi ábrát:

Íme az általános fogalom:

• A sablonok opcionálisan megadhatnak olyan bemeneteket, amelyeket a felhasználó megadhat. Amikor egy fejlesztő elindít egy adott műveletet, kiválaszt egy sablont (még akkor is, ha nem így ír le), és bármilyen bemenetet megad.
• A sablonnal kapcsolatos bemenetekre való hivatkozás kéréssé válik a fejlesztői platform API-ban.
• A kérés elküldése után a kérelem ú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őútvonal-sablonja a kérelemben annak a fejlesztői platformszolgáltatónak, ahonnan a sablon származik.
• A fejlesztői platform szolgáltatója ezután végrehajtja a megvalósításhoz szükséges lépéseket.
• (Nem kötelező) A fejlesztői platform szolgáltatója a művelet végrehajtása közben frissíti a kérés állapotát.
• A kérés teljesítését követően a fejlesztői platform szolgáltatója visszaadhat egy entitáskészletet, amelyet a fejlesztői platform gráfjában adhat hozzá vagy frissíthet. Ezek lehetnek szolgáltatóspecifikus vagy gyakori entitások.

A fejlettebb interakciók támogatásához a fejlesztői platformszolgáltatók közvetlenül meghívhatjá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 is igényeljenek.

Válasszon egy általános feladatot vagy munkafolyamat-motort használó fejlesztői platformszolgáltatót. Pontosabban, valami olyat szeretne, ami összeköti a szoftvermérnöki rendszerek alkalmazása részeként összeállított elemeket. Az egyik általános munkafolyamat- vagy feladatvégrehajtási rendszer, amibe érdemes befektetni, egy CI/CD rendszer.

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

Tekintsük át röviden, 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 egy 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ájljába. 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.

Ezeknek a munkafolyamatoknak vagy folyamatoknak nem kell az alkalmazás forráskódtáraiban lenniük. A koncepció az lenne, hogy kihasználja ezt a tényt, hogy tegyen valamit, mint ez:

• A platformmérnökök vagy a DevOps-csapat tagjai fenntarthatják a munkafolyamatokat és folyamatokat egy vagy több olyan központi adattárban, amelyhez maguk a fejlesztők nem férnek hozzá, de a fejlesztői platform szolgáltatója használatra van beállítva. Ugyanez az adattár tartalmazhat szkripteket és IaC-kódrészleteket, amelyeket a munkafolyamatok/ folyamatok használnak.
• Ha lehetővé szeretné tenni, hogy ezek a munkafolyamatok/folyamatok a megfelelő alsóbb rétegbeli rendszerrel kommunikáljanak, a platformmérnöki csapat ops vagy más tagjai hozzáadhatják a szükséges titkos kulcsokat a központi adattárban. Ennek részleteiért tekintse meg a GitHub Actions és az Azure DevOps dokumentációját , vagy dönthet úgy, hogy központosítja a titkos kulcsokat az Azure Key Vaulthoz hasonló módon.
• Ezek a munkafolyamatok/folyamatok ezután követhetnek egy modellt, amelyben az eredményül kapott entitásokat build/üzembehelyezési összetevőként teszik közzé (GitHub-dokumentumok, Azure DevOps-dokumentumok).
• Futtatás közben a fejlesztői platform szolgáltatója nyomon követheti a munkafolyamat/folyamat állapotát, és frissítheti az életciklus státuszát az orchestrátorban, amíg be nem fejeződik. A frissítések nyomon követéséhez használhat például webhookokat a GitHub Actions-szel és szolgáltatáshorgokat az Azure Pipelines-szel.
• Ha elkészült, a szolgáltató szükség szerint felhasználhatja a közzétett összetevőt a fejlesztői platform gráfba való felvételéhez.

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

A CI/CD-rendszerek használatának nagyszerű módja, hogy gyakran úgy vannak beállítva, hogy tetszőleges CLI-k futtatását támogassák, így nincs szükség első osztályú, egyedi integrációra minden teendőjéhez. Ezeket igény szerint hozzáadhatja.

Az ebben a példában leírtak 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 nem szükséges, hogy azokat a tényleges CI/CD-folyamatokhoz is használja.

Más példák

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

Example	Description
Forrásvezérlő műveletei	Bizonyos esetekben előfordulhat, hogy létre kell hoznia vagy frissítenie kell egy adattárat, be kell küldenie egy lekéréses kérelmet, vagy egy másik, forrásvezérléssel kapcsolatos műveletet kell végrehajtania. Bár az általános aszinkron munkafolyamat-motorok képesek kezelni ezeket a műveleteket, az alapvető Git-műveletek anélkül is hasznosak lehetnek.
Infrastruktúra-kiépítők	Bár a GitHub Actions és az Azure Pipelines jól működik az infrastruktúra kiépítésének kezeléséhez, a közvetlenebb integrációk mellett is dönthet. Egy dedikált szolgáltató egyszerűsítheti a telepítést, és elkerülheti a többletterhelést. Az olyan szolgáltatások, mint az Azure Deployment Environments vagy a Terraform Cloud, közvetlenebbül összpontosítanak az IaC-sablonokkal történő üzembe helyezés lehetővé tételére biztonságosan. Ilyenek lehetnek például a Kubernetes-névterek létrehozása megosztott fürtökben lévő alkalmazásokhoz, vagy a Git használata GitOps-munkafolyamatokkal a Flux vagy az Argo CD használatával adott szolgáltatótípusként. Még több alkalmazásközpontú modell, például a kísérleti Radius OSS-inkubációs projekt saját CLI-kkel, idővel saját fejlesztői platformszolgáltatókkal rendelkezhet. A legfontosabb dolog, hogy keresse meg és tervezze meg a bővíthetőséget, hogy alkalmazkodni tudjon.
Alkalmazás állványozása / vetés	Az alkalmazássablonok fontos részét képezik annak, hogy a platformfejlesztés hogyan vezet az idő múlásával. A választott sablonmotort úgy támogathatja, hogy egy dedikált fejlesztői platformszolgáltatót biztosít, amely úgy van kialakítva, hogy ne csak az alkalmazás forrásfáját bontsa ki, hanem tartalmakat is létrehozhat és leküldhet egy forráskódtárba, és hozzáadhatja az eredményül kapott entitásokat a gráfhoz. Minden ökoszisztémának saját alkalmazás-állványozási előnyben kell részesítenie magát, legyen az Yeoman, a cookiecutter vagy valami hasonló az Azure Developer CLI-hez, így az itt található szolgáltatói modell lehetővé teszi, hogy ugyanazon felületekről több is támogatott legyen. Itt is a bővíthetőség a legfontosabb.
Manuális folyamatok	Függetlenül attól, hogy automatikusan létrehoz egy PR-t manuális jóváhagyásra, vagy manuális munkafolyamat-lépéseket a nem fejlesztők számára a Power Platformhoz hasonló eszközök használatával való válaszadáshoz, ugyanez a sablonalapú modell használható a fejlesztői platformszolgáltatónál. Az idő múlásával akár több automatizált lépésre is áttérhet.

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 az önkiszolgáló alaprendszer hogyan kezelje a nagyobb kihívást jelentő problémákat ezeknek a rendszereknek az integrálásával. Íme egy stratégia az identitással, a felhasználókkal és a csapatokkal kapcsolatos gyakori kihívások kezelésére.

Recommendation	Description
Integrálja a fejlesztői platform API-t közvetlenül az identitásszolgáltatóval az optimális biztonság érdekében.	A fejlesztői platform API védelme érdekében javasoljuk, hogy közvetlen integrációt biztosítsunk egy identitásszolgáltatóval, például a Microsoft Entra ID-val, mivel robusztus identitással és Az Entra ID RBAC-képességeivel rendelkezik. Az identitásszolgáltató natív SDK-jait és API-jait (például az MSAL Entra ID-n keresztül) számos előnnyel jár közvetlenül használni, és nem absztrakción keresztül. A teljes körű biztonságot vezérelheti, és az RBAC-modellre támaszkodhat, miközben biztosítja a feltételes hozzáférési szabályzatok folyamatos kiértékelését (szemben a bejelentkezéskor használtakkal).
Használjon egyszeri bejelentkezést és identitásszolgáltatói csoportintegrációkat az alsóbb rétegbeli rendszerekben.	Az egyszeri bejelentkezés (SSO) integrációinak ugyanazt az identitásszolgáltatót és bérlőt kell használniuk, amelyet a fejlesztői platform API-hoz használ. Emellett mindenképpen használja ki az olyan protokollok támogatását, mint az SCIM, hogy identitásszolgáltatói csoportokkal (például AD-csoportokkal) kapcsolja össze. Az identitásszolgáltatói csoportok alsóbb rétegbeli rendszerbeli engedélyekkel való összekapcsolása nem mindig automatikus, de legalább manuálisan társíthatja a szolgáltatócsoportokat az egyes eszközök csoportosítási fogalmaival anélkül, hogy később manuálisan kezelned a tagságot. Kombinálhatja például a GitHub Vállalati felügyelt felhasználó (EMU) támogatását, valamint manuálisan kihasználhatja az identitásszolgáltatói csoportok GitHub-csapatokhoz való kapcsolásának lehetőségét. Az Azure DevOps hasonló képességekkel rendelkezik.

Az egyetlen identitásszolgáltatói csoporton túli csapat fogalmának kialakítása

A platformfejlesztés folytatásával 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 jönnie ahhoz, hogy létrehozhassa az RBAC- és adatösszesítési csapat fogalmát.

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és esetében a többszerepkörű 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észről a csoport egy általános identitásszolgáltatói fogalom 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 több identitásszolgáltató csoporthoz is kapcsolódhatnak.

A csapatadatok forrása néhány különböző helyről származhat. Ha például a teams as code (TAC) mintát használja, a fejlesztői platform szolgáltatója figyelheti a tárház fájlmódosításait, és gyorsítótárazhatja őket egy felhasználói profilban és a csapat metaadat-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ációhoz 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 használják közvetlenül az identitásszolgáltatói fogalmakat, sokan elvonják ezt egy csoport vagy felhasználó saját reprezentációjába (még az egyszeri bejelentkezéssel is). 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-k 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álják közvetlenül). Ez megnehezíti a felhasználói vagy csapatszintű adatok szűrését és társítását, hacsak nem tud megfeleltetni a különböző azonosítók között.

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 megfeleltethető legyen közöttük. Az összegzéshez egy biztonságos, naplózható Git-adattár lesz a csapat forrása, a PRs pedig egy ellenőrzött felhasználói felületet biztosít a frissítések elvégzé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.

Így például a következő kapcsolatok tárolhatók 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ó fogad é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 -összesítés egy másik kapcsolódó kihívása a felhasználói azonosítók közötti különbségek. Mint a csapat esetében, 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 ID objektumazonosítója) támogat egy 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 felhasználói jogkivonat nélküli API-n keresztül meg tudja keresni a felhasználói azonosítót egy másik rendszerben, egy adott fejlesztői platformszolgáltató menet közben is 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 az eredményeket gyorsítótárba kell helyeznie a teljesítmény fenntartása érdekében.

Támaszkodás több felhasználói token használatára

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-jának több felhasználói jogkivonat kezelésére is be lehet állítani. Például:

• 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.
• 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.
• Ha azt az esetet szeretné kezelni, ahol nem volt elérhető felhasználói jogkivonat, a szolgáltató egy OAuth-folyamatot aktiválna a lekéréshez.
• 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. Az átadott URI tartalmazna egy nem egyszeri használatú kódot.
• Az API ezután nem hitelesített választ ad vissza az URI-val.
• Ezután bármely UX ezt az URI-t használhatja a böngészőben a megfelelő hitelesítési folyamat irányításához.
• Az átirányítást követően a fejlesztői platform megkapja a szükséges felhasználói tokent, és gyorsítótárazza jövőbeni hivatkozás céljából a felhasználói azonosítóval együtt.
• Az ügyfél ezután újra megpróbálhatja az API-hívást, ami ezután sikeres lesz.

Ez a koncepció egy módszert vázol fel a bonyolult hitelesítés kezelésére, 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étegrendszerenként.

Környezettudatos mélyhivatkozások használata eszközökre és jelentéskészítési rendszerekre

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.

Még ha nem is automatizálással kapcsolatos, a fejlesztői platformszolgáltatók bármilyen szükséges entitást bocsáthatnak ki. Általában azonban nem szeretné az összes részletes adatot a teljes belső fejlesztői platformon a fejlesztői platform gráfjába vinni. Az olyan megfigyelhető megoldások irányítópultjai, mint a Grafana, a Prometheus, a DataDog vagy a kódintelligencia olyan termékekben, mint a SonarQube, és a DevOps-csomagok natív képességei, mint a GitHub és az Azure DevOps, mind képesek. Ehelyett gyakran az a legjobb módszer, ha mély kapcsolatokat hoz létre ezekbe a rendszerekbe. Az entitások elegendő információt biztosíthatnak a hivatkozások létrehozásához anélkül, hogy közvetlenül részletes információkat, például naplótartalmakat tartalmaznak.

Azokban az esetekben, amikor összesített és összefoglalt adatokra van szükség az eszközök között, vagy egyéni metrikákat szeretne létrehozni, a Power BI vagy a Microsoft Fabric jelentéskészítési megoldása lehet a következő megoldás. A csapatadatok egyesítéséhez csatlakozhat 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 című szakaszban leírtak szerint az egyik hely, ahol egyéni irányítópultot szeretne, a belső fejlesztői platform sikerességét méri.

Legyen szelektív minden egyes extra élménnyel, amit létrehoz

Bár vonzó lehet a meglévő képességek újbóli létrehozása egy gyakori portálon, tartsa szem előtt, 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 felfoghatóak és megérthetőek, de a fejlesztők máshol több értéket találhatnak.

Ennek ellenére a modell lehetővé teszi, hogy összesített adatokat használjon a fejlesztői platform gráfjá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-jának a kimenet hatókörét (az indexelés és a gyorsítótárazás mellett).

Azonban még ha egy mélyhivatkozás helyett egyedi UX-t is létre kell hoznia, az összes adat fejlesztői platform grafikonjába való behúzása általában még mindig nem a legjobb módszer. Vegyük például azt a helyzetet, amikor olyan naplókat szeretne megjeleníteni a UX-ban, 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 az UX közvetlenül az alsóbb rétegbeli rendszerekből gyűjthet információkat.

Előfordulhat, hogy a csatlakozáshoz rendszer-rendszer integrációt kell használnia, de miután implementálta a felhasználókban és a csapatokban leírt modellek egyikét, szükség esetén bármilyen tárolt alárendelt felhasználó-/csapatazonosítót vagy felhasználói hitelesítési jogkivonatot használhat.

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

Example	Description
Felderítés és feltárás	Ahogy az egyik platformmérnök fogalmazott: "Ami lelassítja a projekteket, az a kommunikáció, nem pedig a fejlesztői készségek." – Daniel, felhőmérnök, Fortune 500 Media Company. Mivel a szoftver egy csapatsport, az első feladatok közé tartozik egy olyan felhasználói felület létrehozása, amely segíti a csapatok, valamint az általuk birtokolt entitások felfedezését. A csapatközi keresés, a felfedezés és a dokumentumok segítenek előléptetni az újrafelhasználást, és elősegíteni a belső forrásokkal vagy támogatással kapcsolatos együttműködést. A Teams emellett előnyt élvez, hogy minden egy helyen tanálható, beleértve a saját környezeteiket, adattáraikat és más erőforrásaikat, például a dokumentumokat.
Környezetek vagy erőforrások manuális regisztrálása	Bár a fejlesztői platform vezénylője számos dolgot kiépítheti és nyomon követheti, érdemes lehet regisztrálni azokat az erőforrásokat vagy környezeteket is, amelyek már léteznek, vagy amelyek még nem automatizáltak. Itt hasznos lehet egy egyszerű szolgáltató, amely információkat vesz fel egy git-adattárból, és adatokat ad hozzá az erőforrásokhoz/környezetkezeléshez. Ha már rendelkezik szoftverkatalógussal, az is lehetővé válik, hogy integrálja azt a modellbe.
API-katalógus	A fejlesztők által használandó API-k nyomon követése hosszú utat vehet igénybe. Ha még nem rendelkezik valamivel, akár egy egyszerű Git-adattárral is kezdhet, amely az API-kat, azok állapotát képviselő fájlokat tartalmaz, és a jóváhagyási munkafolyamatot pR-k használatával kezelheti. Ezek hozzáadhatók a fejlesztői platform grafikonjához, így megjeleníthetők vagy társíthatók más entitásokkal. A robusztusabb képességek érdekében integrálhat valamit, például a Microsoft API Centerét vagy egy másik terméket.
Licencmegfelelőség	Bizonyos esetekben érdemes lehet áttekinteni a szoftverlicenc-megfelelőséget és a licenchasználatot. A fejlesztői platformok a licencek használatához szükséges automatizálást is hozzáadhatják, de még akkor is, ha a licencek manuálisan vannak hozzárendelve (például egy Git-adattár pr-folyamatán keresztül), a fejlesztők láthatják, hogy mit használnak (és a rendszergazda mindent láthat).
A Kubernetes alkalmazásközpontú nézete	Megosztott Kubernetes-fürtök használata esetén a fejlesztők nehezen találhatják meg és ismerhetik meg alkalmazásuk állapotát a fürt rendszergazdai UX-jén keresztül. A különböző szervezetek dönthetnek úgy, hogy másképp kezelik ezt a problémát, de egy névtér használata egy alkalmazás ábrázolására egy jól ismert módszer. Innen entitásokkal társíthatja az alkalmazás névterét a fürtben és a csapatban, és létrehozhat egy fejlesztőközpontúbb nézetet az alkalmazás állapotáról, és mély hivatkozásokat biztosíthat más eszközökre vagy webes felhasználói felületekre.

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 vonzása megnehezítheti, hogy új felhasználói élmény ezeken a gravitációs központokon kívül megjelenjen és hatást érjen el. 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 azok, amelyeket már használnak.

Ezt szem előtt tartva jó ötlet több felhasználói felület tervezése a platformfejlesztés során. Ez lehetőséget nyújthat az egyszerű, az érték bizonyítására és az összetettebb felületek felé való növekedésre is, amikor szükség merül fel.

A meglévők integrálása

Ha elolvasta a szoftvermérnöki rendszerek alkalmazása és az alkalmazásplatform pontosítása című cikket, valószínűleg azonosította a használni kívánt rendszereket. Mindkét esetben értékelje ki, hogy fejlesztheti-e és bővítheti-e a meglévőt, mielőtt elkezdené az új élmények kiépítését. (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 használnak?)

A 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 felejtsen el azonban odafigyelni arra, hogy kedvenc eszközei és szolgáltatásai rendelkeznek-e bővíthetőségi modellel. Sok előnye származik abból, ha ott kezd. 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 IDE-k
• Az Ön DevOps-eszközkészlete
• A CLI-k egyre bővíthetőbbek is
• Alacsony/kód nélküli környezetek, például a Power Pages

Mindegyik jobb kiindulópontot biztosíthat egy adott szerepkörhöz, mint amit a semmiből hozott létre, mivel ezek már létező középpontok. A közös fejlesztői platform API alapként való használata lehetővé teszi a dolgok cseréjét, a kísérletezést és az időbeli változtatásokat.

A fejlesztői portál létrehozásához fontolja meg a webszerkesztő bővítményeit

Ha webalapú felületet keres a fejlesztőknek, vegye figyelembe, hogy a legújabb trend a szerkesztők és a fejlesztőkörnyezetek webalapú verziói. A VS Code-ot használókhoz hasonlóan sokan rendelkeznek bővítménytámogatással. A VS Code segítségével minden, amit ezekhez a webes felületekhez készít, az helyileg fordítható le dupla előnyre.

Az olyan szolgáltatásokon túl, mint a GitHub Codespaces, vscode.dev a VS Code-szerkesztő ingyenes webes verziója, amely nem tartalmaz számítást, de bizonyos típusú bővítmények támogatását is tartalmazza, 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 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 webes alapot biztosíthat a fejlesztői élményekhez az eszköz mellett.

Ezek a fejlesztőkre összpontosító portálként is 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 hagyunk, 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 és perjelparancsok hasznos módot nyújtanak 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-platformja beépített támogatást nyújt olyan rendszerekhez, mint a Microsoft Teams, a Slack vagy a Discord, ez természetes módja annak, hogy minden nap integrálható egy másik felhasználói felület fejlesztőivel és a kapcsolódó üzemeltetési szerepkörökkel. Ezen kívül mindegyik termék rendelkezik bővíthetőségi modellel.

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

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. Gondolja át ezt célhelyként, nem pedig kiindulópontként. Ha még nem dolgozik önnel egy fejlesztői csapat, ennek a munkának a megkezdéséhez itt az ideje. Minden szervezet más, ezért nincs egyetlen méretre illeszkedő válasz arra, hogy mi legyen az ilyen típusú élményben. Ennek eredményeképpen nincs alapértelmezett válasz egy előre csomagolt termékre, amelyet ma azonnal használhat a jelen formájában hasonló célokra.

Az egyénileg létrehozott, saját üzemeltetésű 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 valamit szeretne bemutatni a felhasználóinak korai visszajelzésekért, akár olyan egyszerűvel is kezdhet, mint a low-code Power Pages, hogy csatlakozzon a közös fejlesztői platform API-jához.

A fejlesztői portálra irányuló újabb erőfeszítések jobban meg vannak véleményezve. Például Backstage.io egy egyéni fejlesztői portál eszközkészlete, amely eredetileg a Spotify igényeinek megfelelően készült. Tartalmaz egy parancssori felületet, amellyel a forrásfát ugyanúgy indíthatja el, mint a create-react-app a React.js.

Portál-eszközkészletként munkát igényel a fejlesztéshez, a testreszabáshoz pedig a TypeScript, a Node.jsés a React ismerete szükséges. A nagyszerű dolog azonban az, hogy eszközkészletként szinte bármit megváltoztathat. Saját szoftverkatalógussal és templating mechanizmussal is rendelkezik, de használatuk nem szükséges, és ez egy jól definiált módszer az új, beépülő moduloknak nevezett kód beírására.

Kapcsolódó tartalom

• Microsoft Power Pages
• Backstage.io
• Szoftvermérnöki rendszerek alkalmazása