Arhitectura platformei de autoservire pentru dezvoltatori
O experiență de autoservire a dezvoltatorului se bazează pe o combinație de concepte, modele și instrumente, care acoperă tehnologii personalizate, gata de utilizare și open-source. Scopul este de a oferi dezvoltatorilor executarea și asigurarea accesului la sarcini guvernate, menținând în același timp vizibilitatea centralizată. Accentul principal ar trebui să fie pe sarcini care sunt fie plictisitoare, fie prea complexe pentru ca dezvoltatorii să le gestioneze independent.
Componentele platformei de autoservire pentru dezvoltatori
O fundație de autoservire pentru dezvoltatori constă din mai multe componente cheie care lucrează împreună pentru a eficientiza și automatiza fluxurile de lucru ale dezvoltatorilor. Aceste componente includ API-ul platformei pentru dezvoltatori, graficul platformei pentru dezvoltatori, orchestratorul platformei pentru dezvoltatori, furnizorii platformei pentru dezvoltatori și metadatele profilului utilizatorului și echipei.
API-ul platformei pentru dezvoltatori acționează ca punct central de interacțiune, servind ca interfață contractuală între experiențele utilizatorilor și alte sisteme. Un API de platformă pentru dezvoltatori ar trebui să permită accesul la date și să conducă acțiunile de asigurare a accesului prin diferite interfețe cu utilizatorul. Acesta servește ca strat principal de autentificare și securitate, restricționând accesul la API-urile brute subiacente, împreună cu datele și operațiunile corespunzătoare. API-ul gestionează profilurile de utilizator, rolurile din cadrul platformei și identificatorii furnizorului de identitate primar pentru a asigura un control adecvat al accesului.
Completarea API-ului Developer Platform este Developer Platform Graph, o structură de date securizată, gestionată, care facilitează descoperirea și asocierea entităților și șabloanelor în cadrul platformei. Entitățile agregă date din mai multe surse, în timp ce șabloanele ghidează intrările utilizatorului pentru automatizare.
Developer Platform Graph vă permite să asociați entități și șabloane de la mai mulți furnizori într-o structură care poate fi căutată. Deși datele pentru aceste entități nu trebuie stocate direct într-o bază de date grafică, interacțiunile cu furnizorii pot fi stocate în cache împreună cu metadatele necesare. Acest grafic devine deosebit de valoros atunci când lucrați cu entități comune contribuite de mai mulți furnizori. De exemplu, API-urile pot proveni din Azure API Center, în timp ce implementările și mediile pot fi extrase din sistemele de implementare continuă. Graficul îmbunătățește experiențele utilizatorilor printr-un API comun, permițând descoperirea, căutarea și guvernarea.
Pentru a executa acțiuni bazate pe șabloane, Developer Platform Orchestrator direcționează și urmărește solicitările, coordonându-se cu furnizorii specializați de platforme pentru dezvoltatori care se integrează cu sistemele din aval. Orchestratorul permite dezvoltatorilor sau sistemelor să solicite acțiuni folosind șabloane, fără a efectua acțiunile direct. Se coordonează cu un motor de activități, un motor de flux de lucru sau un alt orchestrator pentru a executa acțiunile. Această componentă este esențială pentru activarea autoservirii, deoarece permite dezvoltatorilor să declanșeze acțiuni fără a avea nevoie de permisiuni directe. Spre deosebire de CI/CD, aceste acțiuni nu se limitează la codul sursă al aplicației. Motoarele de flux de lucru, cum ar fi GitHub Actions sau Azure Pipelines, pot servi drept orchestratori, dar abstractizarea poate fi utilă pentru a sprijini diferite motoare în timp. Această flexibilitate permite migrarea motorului, acceptă pași manuali pentru procesele care pot fi automatizate ulterior și acceptă acțiuni care vizează roluri care nu sunt de dezvoltare (de exemplu, conturi de plătit). În plus, sarcinile mai simple pot fi gestionate prin solicitări HTTP, evitând nevoia de motoare complexe.
Furnizorii de platforme pentru dezvoltatori gestionează logica pentru operațiunile de creare, citire, actualizare și ștergere (CRUD) pe entități și executarea solicitărilor de acțiune, acceptând diverse fluxuri de lucru și servicii. Furnizorii introduc funcționalități în API printr-un model de furnizor extensibil, permițând caracteristici cheie precum automatizarea și agregarea datelor. Acest model promovează cuplarea liberă, permițând integrarea incrementală a noilor funcționalități și îmbunătățirea întreținerii. Prin promovarea unei mentalități de sursă internă, funcționalitatea platformei poate fi contribuită și întreținută de diferite echipe, minimizând povara de întreținere a echipelor centrale. Deși este esențial să revizuiți codul furnizorului și să gestionați accesul cu atenție, această abordare conectabilă ajută la scalarea efortului de dezvoltare în întreaga organizație.
Fundația include, de asemenea, capabilități pentru gestionarea profilului de utilizator și a metadatelor echipei, care leagă informațiile individuale și de echipă de conturile găzduite de un furnizor de identitate, cum ar fi Microsoft Entra ID. Aceste metadate sunt utilizate pentru gruparea și controlul accesului în cadrul API-ului platformei pentru dezvoltatori. Deși ar fi posibil să stocați aceste informații în Developer Platform Graph, separarea lor asigură claritate.
O fundație de autoservire pentru dezvoltatori este accesibilă printr-o interfață de utilizator centralizată/experiență de utilizator (UI/UX). Oferirea unui punct de acces unificat eficientizează interacțiunile pentru dezvoltatori, facilitând utilizarea fluxurilor de lucru și a resurselor într-o manieră simplă și intuitivă.
O fundație de autoservire pentru dezvoltatori nu trebuie să fie complet construită de la început. În schimb, servește ca un ghid conceptual pentru capacitățile pe care trebuie să le urmărim în timp. Implementările inițiale pot fi simplificate, folosind instrumentele, interfețele sau clasele existente pentru a aborda cele mai presante priorități identificate prin feedback-ul clienților. Începând cu puțin și iterând, fundația poate evolua pentru a satisface în mod eficient noile cerințe.
Concepte cheie ale furnizorului de platforme pentru dezvoltatori
Într-o platformă de dezvoltatori, gestionarea și orchestrarea eficientă a resurselor se bazează pe utilizarea entităților împreună cu proprietățile și șabloanele acestora. Aceste concepte cheie oferă structură și automatizare, permițând integrarea perfectă între diferiți furnizori și facilitând fluxurile de lucru și guvernanța consecvente.
Entități
Entitățile sunt obiectele cheie pe care un dezvoltator sau un sistem trebuie să le urmărească, să le actualizeze, să le prezinte sau să acționeze în cadrul platformei interne pentru dezvoltatori. Aceste entități pot avea relații între ele, formând un grafic care oferă informații cruciale despre platformă. Furnizorii de platforme pentru dezvoltatori pot genera entități pentru a susține diverse capabilități de bază, cum ar fi descoperirea resurselor externe, efectuarea analizei dependențelor sau afișarea informațiilor despre proprietate și întreținere. O interfață de furnizor bine definită simplifică integrarea, testarea și implementarea, permițând în același timp echipelor de dezvoltatori să funcționeze independent.
Proprietăți comune
Pentru a gestiona eficient entitățile, este util să definiți un set de proprietăți comune. Unele proprietăți sugerate includ un identificator unic, un nume, un furnizor de origine și asocieri opționale cu utilizatori, echipe sau alte entități. Aceste proprietăți sunt importante pentru controlul accesului bazat pe roluri (RBAC), descoperirea și agregarea datelor. Implementarea RBAC de la început este esențială pentru securitate și scalarea platformei în timp. Asocierile de utilizatori și de echipă sunt deosebit de valoroase, deoarece ajută la descoperire și colaborare, permițând reutilizarea eficientă, asistența și aprovizionarea internă în cadrul platformei.
Entități comune și specifice furnizorului
De asemenea, ar trebui să definiți un set de entități comune, de nivel înalt, normalizate, pe care mai mulți furnizori le pot produce. Acestea pot include medii, resurse, API-uri, depozite, componente și instrumente. Aceste entități ar trebui să fie conceptuale, concentrându-se pe clasificarea largă (cum ar fi mediile), mai degrabă decât pe detaliile tehnice granulare (de exemplu, infrastructura internă). Această vizualizare de nivel înalt facilitează descoperirea, permițând agregarea datelor în timp, indicând în același timp detalii de nivel inferior din afara sistemului. În plus, pe măsură ce platforma dvs. evoluează, poate fi necesar să găzduiți un set tot mai mare de tipuri de entități specifice furnizorului pentru a satisface diverse cazuri de utilizare.
Șabloane
Șabloanele sunt concepute pentru a stimula acțiuni precum asigurarea accesului la infrastructură, crearea de depozite sau alte procese de lungă durată. Aceste șabloane sunt disponibile prin furnizorii de platforme pentru dezvoltatori și includ proprietăți comune, cum ar fi asocieri de entități și intrări necesare (de exemplu, nume de resurse). Șabloanele pot reprezenta diferite formate, inclusiv șabloane Infrastructure-as-Code (IaC), șabloane de aplicații sau scripturi parametrizate. Acestea sunt adesea specifice furnizorului, cu reprezentări diferite în funcție de tehnologia utilizată. Exemple de astfel de reprezentări includ șabloane Terraform sau Bicep, diagrame Helm, fluxuri de lucru GitHub Actions parametrizate, Azure Pipelines, scripturi simple sau formate personalizate adaptate anumitor ecosisteme de furnizori.
Deși șabloanele nu trebuie stocate central, acestea trebuie să fie accesibile prin intermediul unui furnizor pentru a asigura un acces consecvent pe platformă. Acestea pot exista în diferite depozite, registre sau cataloage, în funcție de cazul de utilizare. De exemplu, depozitele de șabloane GitHub ar putea fi utilizate pentru șabloane de aplicații, în timp ce șabloanele IaC ar putea locui într-un depozit de catalog restricționat pe care dezvoltatorii îl accesează indirect prin instrumente precum Azure Deployment Environments. Alte șabloane IaC pot fi stocate într-un registru de artefacte Open Container Initiative (OCI), cum ar fi diagramele Helm. În unele cazuri, un șablon poate face referire pur și simplu la un punct final HTTP parametrizat.
Inginerii de platformă sau specialiștii în domeniu creează de obicei aceste șabloane și le partajează cu echipele de dezvoltare pentru reutilizare. Centralizarea utilizării șabloanelor într-un sistem facilitează accesul acestora, aplicând în același timp standardele și politicile organizaționale. Acest proces ajută la menținerea controlului și conformității pe platformă, permițând în același timp dezvoltatorilor să lucreze mai eficient.
Acțiuni GitHub ca furnizori de platformă
Pentru a ilustra cum funcționează un furnizor, să luăm în considerare GitHub Actions și Azure Pipelines. Oricare dintre ele poate servi ca furnizor de platforme pentru dezvoltatori prin declanșarea fluxurilor de lucru sau a conductelor prin API-urile respective, cum ar fi API-ul REST GitHub Actions sau API-ul Azure DevOps Pipeline. Aceste fluxuri de lucru sau conducte nu trebuie să fie găzduite în depozitele de cod sursă ale aplicațiilor, permițând inginerilor de platformă să le mențină în depozite centrale, private. În acest model, dezvoltatorii nu au acces direct la fluxurile de lucru, dar pot folosi un furnizor de platformă pentru dezvoltatori pentru a interacționa cu ei. Furnizorul poate gestiona secretele necesare, cum ar fi acreditările sau cheile API, prin integrarea cu servicii precum Azure Key Vault. Pe măsură ce fluxurile de lucru se execută, furnizorul urmărește starea acestora, utilizând webhook-uri pentru GitHub Actions și cârlige de serviciu pentru Azure Pipelines pentru a monitoriza progresul. După finalizarea fluxului de lucru, toate artefactele produse, cum ar fi rezultatele compilării sau implementării, sunt capturate și publicate. Aceste artefacte, împreună cu parametrii de intrare și referințele la fluxurile de lucru, pot fi adăugate la graficul platformei dezvoltatorului. Această abordare permite, de asemenea, flexibilitate în utilizarea CLI-urilor arbitrare, susținând o gamă largă de sarcini de automatizare în timp. În plus, utilizarea GitHub Actions sau Azure Pipelines în acest context este independentă de rolul lor tradițional în CI/CD, oferind o aplicabilitate mai largă pentru gestionarea diferitelor procese și șabloane.
Există și alte tipuri de furnizori de platforme pentru dezvoltatori, care se pot ocupa de diverse sarcini prin șabloane. Pentru operațiunile de control sursă, furnizorii pot ajuta la gestionarea activităților Git, cum ar fi crearea de depozite, trimiterea PR-urilor sau alte operațiuni Git fără a se baza pe motoarele generale de flux de lucru. Aprovizionarea infrastructurii poate fi simplificată prin furnizori dedicați, cum ar fi Azure Deployment Environments sau Terraform Cloud, concentrându-se pe Infrastructure as Code (IaC) cu securitate și eficiență. Furnizorii de schele de aplicații, cum ar fi Azure Developer CLI, acceptă crearea arborilor sursă de aplicații și împingerea lor în depozitele sursă, adăugând flexibilitate pentru diferite ecosisteme. Procesele manuale, cum ar fi generarea de solicitări de extragere (PR) sau automatizarea fluxurilor de lucru pentru non-dezvoltatori, pot fi, de asemenea, gestionate prin furnizori bazați pe șabloane, permițând automatizarea treptată. Aceste exemple evidențiază modul în care extensibilitatea și adaptabilitatea furnizorilor de platforme pentru dezvoltatori pot îmbunătăți capacitățile de automatizare în timp.