Progettare una base self-service per sviluppatori

Una volta ottenuta una buona conoscenza della destinazione per i sistemi di progettazione, è possibile creare esperienze self-service più sofisticate per sviluppatori. Un'esperienza self-service per sviluppatori si basa su concetti, modelli e componenti.

Anche se non sono necessari tutti gli elementi descritti qui nell'organizzazione, è consigliabile tenere presenti questi concetti se si compila un elemento personalizzato o si valutano i prodotti correlati. Il modello di esperienza self-service dello sviluppatore può essere costituito da una combinazione di prodotti home-grown, off-the-shelf e open source. I prodotti o i toolkit del portale open source come Backstage.io potrebbero usare termini diversi per alcuni elementi del modello descritto qui, ma il modello può comunque aiutare a orientarsi.

Automatizzare i flussi di lavoro, aggregare i dati, iniziare in modo semplice ed espandersi gradualmente

L'obiettivo è abilitare un servizio autonomo con misure di sicurezza tramite l'esecuzione e il provisioning di attività controllate e regolate, oltre alla visibilità centralizzata. Le aree più importanti da concentrarsi sono quelle noiose o che lo sviluppatore non può fare a causa di complessità o autorizzazioni. Questo ultimo elemento è importante per consentire di seguire il principio dei privilegi minimi senza forzare gli sviluppatori attraverso un processo manuale del service desk.

Anche se è possibile scegliere di estendere la famiglia di prodotti DevOps per soddisfare queste esigenze, è probabile che sia necessario supportare più piattaforme applicative nel tempo e anche gli strumenti e i processi specifici che li supportano potrebbero dover cambiare. Il problema principale è che i tuoi standard sono un bersaglio mobile. Come affermato da un professionista dell'ingegneria della piattaforma:

Le difficoltà comportano la standardizzazione ... e affrontando il tema del 'software abbandonato'... La standardizzazione spesso non viene raggiunta a causa di potenziali interruzioni dei processi automatizzati e dell'attività che richiede molto tempo per identificare le modifiche necessarie. - Martin, ingegnere DevOps, grande azienda logistica

Il passaggio rapido a uno standard nuovo o aggiornato non è in genere fattibile e l'abbandono dei processi esistenti crea rischi. L'organizzazione potrebbe già usare più suite DevOps o combinazioni diverse di singoli strumenti e servizi per sviluppatori in base allo scenario. Anche con un team centrale e una soluzione standard, poiché le esigenze self-service aumentano, la variabilità è inevitabile. Si vuole quindi consentire la sperimentazione controllata in cui i team designati potrebbero provare nuove tecnologie, strategie di distribuzione e così via, seguite dall'adozione intenzionale e da un'implementazione incrementale.

In genere le esperienze self-service rientrano in due categorie principali: automazione e aggregazione dei dati.

Anche se l'aggregazione dei dati crea esperienze utente valide, l'automazione è più importante:

L'automazione è fondamentale e sarà amata da tutti. L'aggregazione dei dati è secondaria. – Peter, responsabile dell'ingegneria della piattaforma, società tecnologica multinazionale

Nel percorso di progettazione della piattaforma sono stati identificati i problemi potenzialmente risolti dall'automazione. Oltre a ridurre il carico cognitivo e la fatica degli sviluppatori, l'automazione può anche aiutare a garantire che le applicazioni siano connesse ai migliori strumenti e servizi per operazioni, sicurezza e altri ruoli per svolgere il proprio lavoro.

Tuttavia, se si lavora con più di un sistema per guidare l'automazione, un certo livello di aggregazione dei dati è utile per tenere traccia delle richieste automatizzate e dei risultati associati. Per iniziare, è possibile collegarsi a sistemi esterni per soddisfare altre esigenze o per informazioni dettagliate. L'aggregazione e la visibilità dei dati sono importanti anche per il controllo, la governance e la riduzione dei rifiuti (ad esempio, ambienti inutilizzati).

L'automazione di elementi come il provisioning dell'infrastruttura può essere eseguita usando le integrazioni di sistema, ma è anche possibile attivare e facilitare un processo manuale del flusso di lavoro che sembra automatizzato per lo sviluppatore. Ciò è utile nelle prime fasi della piattaforma, per i nuovi prodotti che stai introducendo nell'ecosistema o in aree che non hai o non puoi automatizzare l'uso di un sistema (ad esempio, assegnazione di licenze software). Con la progettazione corretta, è possibile iniziare con un processo manuale facilitato da qualcosa come Power Automate che si passa a un flusso completamente automatizzato nel tempo. Quindi, progettare per un'automazione fin dall'inizio.

Per iniziare, è possibile riutilizzare gli investimenti esistenti, ad esempio i sistemi di progettazione o un portale interno, quindi passare alla creazione di CLI, pagine Web di base o persino Power Pages, Power BI o dashboard Microsoft Fabric ed espandersi in base alle esigenze. La presenza di un'API coerente che usa l'esperienza utente può essere utile per supportare più interfacce nel tempo man mano che cambiano le esigenze e le preferenze.

Componenti della piattaforma self-service per sviluppatori: API, grafo, agente di orchestrazione, provider e metadati

Considerare le basi del self-service per sviluppatori:

Come illustrato nella figura, i componenti seguenti costituiscono il nucleo del concetto di base self-service per sviluppatori:

Componente	Description
API della piattaforma per sviluppatori	Il singolo punto di contatto per le esperienze utente. È effettivamente il contratto del sistema con altri sistemi.
Grafico della piattaforma per sviluppatori	Grafico dei dati gestito e sicuro che consente di individuare, associare e usare diversi tipi di entità e modelli. Un'entità è un oggetto che abilita l'aggregazione dei dati da più origini, mentre i modelli determinano input utente che abilitano l'automazione.
Agente di orchestrazione della piattaforma per sviluppatori	Funzionalità che indirizza e tiene traccia delle richieste basate su modello per eseguire azioni in un sistema o tramite un processo manuale. Queste richieste vengono instradate a un set di provider di piattaforme per sviluppatori che possono integrarsi in qualsiasi numero di sistemi di flusso di lavoro diversi o altri servizi.
Provider di piattaforme per sviluppatori	Set di componenti che incapsulano la logica necessaria per l'integrazione con sistemi downstream per supportare operazioni CRUD su entità o evasione delle richieste di azioni basate su modello. Ogni provider può supportare il proprio tipo specifico di modelli e generare tipi univoci o comuni di entità.
Metadati del profilo utente e del team	Possibilità di rendere persistenti le informazioni su un set di utenti associati a un team concettuale per il raggruppamento e l'accesso all'API della piattaforma per sviluppatori. L'utente è strettamente associato a un account del provider di identità (ad esempio, l'accesso con ID Microsoft Entra), ma sia esso sia un team possono associare qualsiasi numero di rappresentazioni di sistemi downstream correlati. Un'implementazione di questo archivio informazioni consiste nel riutilizzare il grafico della piattaforma per sviluppatori. La base self-service dello sviluppatore può stabilire un tipo di entità comune per un utente e un team e rendere persistenti tali informazioni nel grafico. Tuttavia, manterremo questo negozio separato per maggiore chiarezza.

Questi componenti fondamentali consentono di usare e scambiare blocchi predefiniti diversi nel tempo.

Devo creare tutto questo per iniziare?

No In primo luogo, si tratta di un modello concettuale che aiuta a capire cosa dovrebbe essere in grado di fare una fondazione come questa una volta completata. In secondo luogo, le specifiche dell'implementazione sono meno importanti, dato che l'API della piattaforma per sviluppatori diventa l'interfaccia chiave. L'implementazione iniziale potrebbe iniziare a usare interfacce e classi nel codice per i diversi livelli descritti o combinarli in altri prodotti. È anche possibile omettere aspetti perché l'analisi dello sviluppo del cliente indica che è semplicemente una priorità più bassa. Inizia con quello che hai e cresce.

API della piattaforma per sviluppatori

È necessario definire un'API della piattaforma per sviluppatori per fungere da contratto del sistema. L'API viene utilizzata da diverse interfacce utente per abilitare l'accesso ai dati, la fornitura delle risorse e altre azioni.

Questa API funge da livello importante di autenticazione e sicurezza limitando l'accesso alle API sottostanti non elaborate in altri sistemi a dati e operazioni più specifici e controllati. L'API fornisce l'accesso alla propria rappresentazione di un profilo utente, al ruolo generale di un utente all'interno della piattaforma (membro del team, amministratore e così via) e agli identificatori di sistema del provider di identità primario. Per altre informazioni, vedere Utenti e team.

Provider di piattaforme per sviluppatori

Data l'ampiezza di una piattaforma per sviluppatori interna, è necessario creare o identificare sistemi che seguono un modello di provider estendibile per introdurre funzionalità nell'API. L'idea è che le funzionalità chiave come l'automazione e l'aggregazione dei dati vengono fornite interagendo con componenti collegabili con interfacce ben definite. Questo accoppiamento libero consente di collegare ciò che è necessario in modo incrementale e migliorare la manutenibilità perché è possibile testare le funzionalità indipendentemente dal resto della base.

È anche un modo importante per abilitare una mentalità di origine interna scalabile per la piattaforma. In genere, gli sforzi di inner sourcing in ambito platform engineering non riescono a ottenere trazione a causa delle sfide legate alla manutenzione continua. Altri team potrebbero essere disposti a contribuire alle funzionalità, ma sono meno propensi a mantenere e testare qualcosa all'interno del nucleo della piattaforma. Al contrario, qualsiasi team centralizzato ha capacità limitata per mantenere il codice fornito o persino esaminare le richieste pull. Il concetto di provider di piattaforme per sviluppatori riduce questa tensione consentendo a codice scritto in modo indipendente di collegare le funzionalità di base all'interno della base self-service dello sviluppatore. Anche se è consigliabile gestire attentamente i provider usati, esaminare qualsiasi codice del provider e limitare la superficie di attacco a cui un determinato provider può accedere nella piattaforma per sviluppatori, un approccio collegabile può aiutare a fare di più ridimensionando lo sforzo in una parte più ampia dell'organizzazione.

Concetti chiave del provider di piattaforme per sviluppatori

Entities

Il concetto di entità è un elemento su cui uno sviluppatore o un altro sistema nella piattaforma per sviluppatori interna deve tenere traccia, aggiornare, presentare o agire. Le entità possono avere relazioni tra loro che, se usate insieme, costituiscono un grafo che fornisce informazioni critiche sulle parti della piattaforma per sviluppatori interna. I provider della piattaforma per sviluppatori possono quindi restituire entità per abilitare le funzionalità principali, tra cui:

• Rendere visibili risorse/ambienti forniti esternamente o API disponibili per l’individuazione e l'uso
• Esposizione delle relazioni per l'analisi delle dipendenze, dell'impatto, della scoperta, ecc.
• Emerge informazioni sui responsabili/possessori per la scoperta e collaborazione
• Visualizzazione di più dati per l'uso nelle esperienze utente

L'incapsulamento di questa funzionalità in un'interfaccia del provider di piattaforme per sviluppatori ben definita semplifica l'integrazione e il test, abilita la distribuzione indipendente e consente agli sviluppatori esterni al team principale della piattaforma per sviluppatori interna di contribuire e gestire i provider. Questo aspetto è importante nelle organizzazioni di grandi dimensioni o divisioni in cui non tutti gli strumenti, i servizi o la piattaforma vengono gestiti centralmente, ma l'organizzazione più ampia vuole comunque condividere le funzionalità. ** Quindi, anche se inizialmente non si intraprende questo percorso, è qualcosa da considerare sul lungo termine.

Proprietà comuni

Ogni entità deve avere un set di proprietà comuni per consentire alla fondazione di gestirle. Alcune proprietà da considerare includono:

• Identificatore univoco
• Nome
• Fornitore di origine
• Associazioni facoltative per:
  • Utente proprietario
  • Squadra proprietaria
  • Altre entità

Le proprietà utente e team sono importanti per tre motivi: controllo degli accessi in base al ruolo, individuazione e aggregazione dei dati , ad esempio riepiloghi a livello di team. L'integrazione del controllo degli accessi in base al ruolo fin dall'inizio è fondamentale per la sicurezza e la crescita nel tempo della piattaforma per sviluppatori interna. Poiché lo sviluppo è un lavoro di squadra, scoprire a chi parlare di un'entità diventerà rapidamente fondamentale per il riutilizzo, il supporto e l'innersourcing.

Entità comuni e specifiche del provider

È anche possibile stabilire un set di entità comuni normalizzate di alto livello che più provider possono restituire. Per esempio:

• Environments
• Risorse
• API
• Repository
• Components
• Tools

In genere dovrebbero essere di alto livello, come nel contesto del modello C4 o al massimo nei diagrammi dei componenti di alto livello. Ad esempio, per un ambiente, non è necessario includere i dettagli della topografia dell'infrastruttura interna; sono necessarie informazioni sufficienti per elencare e associare ambienti concettuali diversi da più provider nella stessa esperienza utente. L'entità può fare riferimento a livelli di dettaglio inferiori al di fuori del sistema piuttosto che cercare di utilizzare tutto. Questi forniscono punti di partenza per l'individuazione che sono fondamentali per abilitare l'aggregazione dei dati nel tempo.

Altri sono specifici di un particolare caso d'uso o provider, quindi è consigliabile considerare come gestire un set crescente di tipi di entità nel tempo.

Modelli

Il concetto di modello in questo contesto è diverso dall'idea delle entità in quanto sono destinate a guidare un'azione. Gli scenari di esempio includono il provisioning dell'infrastruttura, la creazione di un repository e altri processi a esecuzione prolungata. Questi modelli devono essere disponibili anche tramite provider di piattaforme per sviluppatori estendibili e devono supportare le stesse proprietà comuni delle entità, incluse le associazioni di entità.

Tuttavia, possono anche definire gli input necessari, sia specificati dal sistema che dall'utente, per eseguire l'azione. Questi valori possono includere qualsiasi cosa, come nominare la risorsa alle aggiunte facoltative.

Esempi di modelli includono:

• Modelli di infrastruttura come codice (IaC)
• Modelli di applicazione (inizia a destra) o repository di modelli
• Creare modelli di pipeline/flusso di lavoro
• Pipeline di distribuzione/modelli di flusso di lavoro
• Script con parametri
• Flussi di Power Automate con parametri (ad esempio, un flusso cloud attivato da una richiesta HTTP)
• Modelli di messaggio e-mail

Analogamente alle entità, i modelli possono includere proprietà specifiche del provider.

Ogni modello potrebbe avere una rappresentazione diversa univoca per il provider. Possono variare da modelli Terraform o ARM a grafici Helm, flussi di lavoro gitHub Actions con parametri o Azure Pipelines, script semplici o formati personalizzati.

I dettagli effettivi del modello sottostante non devono necessariamente essere archiviati centralmente. Possono esistere in diversi repository, diversi registri o diversi cataloghi. Ad esempio, è possibile usare repository di modelli GitHub per i modelli di applicazione, mentre i modelli IaC potrebbero esistere in un repository di cataloghi con restrizioni a cui gli sviluppatori possono accedere solo indirettamente tramite ambienti di distribuzione di Azure. Altri modelli IaC potrebbero essere archiviati in un Registro artefatti OCI come i grafici Helm. In altri casi, il modello potrebbe essere un riferimento a un endpoint HTTP con parametri. Un provider di piattaforme per sviluppatori deve fornire informazioni sufficienti su ogni tipo di modello in modo che possano essere referenziate e tutte le opzioni esposte per l'uso nelle esperienze utente. Tuttavia, i modelli possono essere collocati nella posizione più adatta per i casi d'uso.

I tecnici della piattaforma o gli esperti in un'area specifica scrivono modelli e quindi li condividono con i team di sviluppo per il riutilizzo. Centralizzare l'uso di questi modelli tramite un sistema consente agli sviluppatori self-service e crea protezioni che consentono di applicare la conformità agli standard o ai criteri dell'organizzazione. Altre informazioni su questo argomento quando parleremo dell'orchestratore della piattaforma per sviluppatori tra poco.

Grafico della piattaforma per sviluppatori

È possibile considerare un grafico della piattaforma per sviluppatori come qualcosa che consente di associare entità e modelli da più provider in un grafico ricercabile. Tuttavia, i dati effettivi per le entità non devono necessariamente essere archiviati direttamente in un database specifico per grafi. Al contrario, le interazioni con i provider potrebbero essere memorizzate nella cache insieme ai metadati necessari per renderle tutte insieme.

Quando usato con entità comuni a cui più provider potrebbero contribuire, il grafico è potente. Ad esempio, un elenco di API potrebbe provenire da un prodotto come centro API di Azure, ma potrebbe anche essere utile inserire automaticamente distribuzioni e ambienti dai sistemi di distribuzione continua. Nel corso del tempo, è possibile passare da sistemi di distribuzione diversi o addirittura supportare più di un sistema di distribuzione. A condizione che ogni sistema di distribuzione disponga di un provider di piattaforme per sviluppatori, si dovrebbe comunque essere in grado di creare l'associazione.

Ognuna delle esperienze utente create da questo grafo può quindi sfruttare un'API comune per ottimizzare l'individuazione, la ricerca, la governance e altro ancora. Un agente di orchestrazione della piattaforma per sviluppatori può quindi sfruttare questo stesso grafico in modo che tutte le azioni eseguite da un provider di piattaforme per sviluppatori contribuiscano automaticamente alle entità disponibili per la stessa API.

Agente di orchestrazione della piattaforma per sviluppatori

Un agente di orchestrazione della piattaforma per sviluppatori consente agli sviluppatori o ai sistemi di creare richieste per eseguire un'azione usando un modello. Non esegue queste azioni, ma coordina invece con un motore di attività, un motore del flusso di lavoro o un altro agente di orchestrazione a tale scopo. È uno dei componenti critici di cui vuoi essere sicuro faccia parte della tua infrastruttura self-service. Consente agli sviluppatori di creare richieste con un modello o di eseguire un'azione senza autorizzazione diretta. Inoltre, a differenza del concetto di CI o CD, queste azioni non devono essere correlate al codice sorgente dell'applicazione.

È possibile usare GitHub Actions, Azure Pipelines o un altro motore del flusso di lavoro come agente di orchestrazione. Si tratta di un luogo ragionevole per iniziare, ma potrebbe essere necessario avere un po 'di astrazione per consentire a diversi tipi di modelli di usare motori sottostanti diversi. Questo può essere utile per alcuni motivi:

• In primo luogo, è probabile che si voglia essere in grado di selezionare diversi motori di esecuzione di flussi di lavoro e attività nel tempo senza dover tagliare flash. Consentendo più di un motore, è possibile avviare una migrazione graduale o semplicemente passare all'uso del nuovo motore per nuove azioni senza influire su quelli esistenti.
• Alcuni processi che si vogliono aiutare a orchestrare potrebbero richiedere inizialmente passaggi manuali anche se si prevede di automatizzarli completamente in un secondo momento.
• Altre azioni possono essere destinate a ruoli esterni al team di sviluppo, ad esempio gli account pagabili o un amministratore della licenza. I motori a basso codice come Power Automate spesso funzionano bene per questi ruoli.
• Altre azioni possono essere gestite tramite semplici richieste HTTP in cui impostare qualcosa di potente come GitHub Actions o Azure Pipelines non è necessario o economicamente vantaggioso per la scalabilità.

Fortunatamente, espandendo l'idea di un provider di piattaforme per sviluppatori per coprire i passaggi di attivazione e rilevamento dell'automazione può fornire questa astrazione necessaria. Si consideri la figura seguente:

Ecco il concetto generale:

• I modelli possono facoltativamente specificare un set di input che l'utente può immettere. Quando uno sviluppatore attiva una determinata azione, seleziona un modello (anche se non descritto in questo modo) e immetti eventuali input.
• Un riferimento agli input correlati al modello diventa una richiesta nell'API della piattaforma per sviluppatori.
• Dopo l'invio di una richiesta, un componente di gestione e routing delle richieste all'interno dell'agente di orchestrazione inizia a tenere traccia del ciclo di vita della richiesta. Modello di routing delle richieste e gestione delle route dei componenti nella richiesta al provider della piattaforma per sviluppatori in cui è stato originato il modello.
• Il provider della piattaforma per sviluppatori esegue quindi i passaggi appropriati per l'implementazione.
• (Facoltativo) Il provider della piattaforma per sviluppatori aggiorna lo stato della richiesta durante l'esecuzione dell'azione.
• Una volta soddisfatta la richiesta, il provider della piattaforma per sviluppatori può restituire un set di entità da aggiungere o aggiornare nel grafico della piattaforma per sviluppatori. Possono trattarsi di entità specifiche o comuni del provider.

Facoltativamente, per supportare interazioni più avanzate, i provider di piattaforme per sviluppatori possono chiamare direttamente l'API della piattaforma per sviluppatori per ottenere più entità come input o persino richiedere un'altra azione correlata.

Selezionare un provider di piattaforme per sviluppatori che usa un'attività generale o un motore del flusso di lavoro. In particolare, si vuole qualcosa per collegare ciò che si mette insieme come parte di Applicare sistemi di ingegneria software. Un flusso di lavoro generale o un motore di esecuzione delle attività da investire in è un sistema CI/CD.

Esempio di uso di GitHub Actions o Azure Pipelines

Si esaminerà brevemente il funzionamento di gitHub Actions o Azure Pipelines come provider di piattaforme per sviluppatori.

Per GitHub Actions, la chiave per eseguire questa operazione è che un provider di piattaforme per sviluppatori può connettersi all'istanza di GitHub specificata e usare l'API REST Actions per generare un evento dispatch del flusso di lavoro per attivare un'esecuzione del flusso di lavoro. Ogni flusso di lavoro può supportare un set di input aggiungendo una configurazione workflow_dispatch al file YAML del flusso di lavoro. I trigger di Azure DevOps sono simili ed è anche possibile usare l'API della pipeline di Azure DevOps per le esecuzioni. Probabilmente verranno visualizzate le stesse funzionalità in altri prodotti.

Questi flussi di lavoro o pipeline non devono trovarsi nei repository di codice sorgente dell'applicazione. Il concetto sarebbe quello di sfruttare questo fatto per eseguire un'operazione simile alla seguente:

• I tecnici della piattaforma o i membri del team DevOps possono gestire i flussi di lavoro/pipeline in uno o più repository centrali a cui gli sviluppatori stessi non hanno accesso, ma il provider della piattaforma per sviluppatori è configurato per l'uso. Lo stesso repository può includere script e frammenti di codice IaC usati dai flussi di lavoro/pipeline.
• Per consentire a questi flussi di lavoro/pipeline di interagire con il sistema downstream appropriato, il team delle operazioni o altri membri del team di ingegneria di piattaforma possono aggiungere i segreti necessari nel repository centrale. Per informazioni dettagliate su come eseguire questa operazione, vedere la documentazione di GitHub Actions e Azure DevOps oppure è possibile scegliere di centralizzare i segreti usando un'istanza come Azure Key Vault.
• Questi flussi di lavoro/pipeline possono quindi seguire un modello in cui pubblicano qualsiasi entità risultante come artefatto di compilazione/distribuzione (documentazione di GitHub, documentazione di Azure DevOps).
• Durante un'esecuzione, il provider della piattaforma per sviluppatori può quindi controllare lo stato del flusso di lavoro/pipeline e aggiornare lo stato del ciclo di vita nell'orchestratore fino a che non sia completato. Ad esempio, è possibile usare web hook con GitHub Actions e hook del servizio con Azure Pipelines per tenere traccia degli aggiornamenti.
• Al termine, il provider può quindi utilizzare l'artefatto pubblicato per l'inclusione nel grafico della piattaforma per sviluppatori in base alle esigenze.

Infine, è possibile configurare questo provider di piattaforme per sviluppatori per l'output di un set di modelli nel grafico della piattaforma per sviluppatori che fanno riferimento al repository e al flusso di lavoro/pipeline appropriati, insieme agli input per una determinata attività.

La cosa importante dell'uso di un sistema CI/CD è che sono spesso configurati per supportare l'esecuzione di CLI arbitrari, quindi non è necessaria un'integrazione univoca di prima classe per tutto ciò che si fa. È possibile aggiungerli nel tempo in base alle esigenze.

Gran parte di ciò che viene descritto in questo esempio si applica al funzionamento di altri tipi di provider. È anche importante notare che l'uso di GitHub Actions o Azure Pipelines in questo contesto non richiede di utilizzarli anche per le pipeline CI/CD.

Altri esempi

Ecco alcuni esempi di altri tipi di provider di piattaforme per sviluppatori che potrebbero elaborare i modelli.

Example	Description
Operazioni di controllo del codice sorgente	In alcuni casi, potrebbe essere necessario creare o aggiornare un repository, inviare una richiesta di pull o eseguire un'altra operazione correlata al controllo del codice sorgente. Anche se i motori di flusso di lavoro asincroni generali possono gestire questi tipi di operazioni, poter eseguire operazioni Git di base senza un motore può essere utile.
Provisioner dell'infrastruttura	Anche se GitHub Actions e Azure Pipelines funzionano bene per la gestione del provisioning dell'infrastruttura, è possibile scegliere anche integrazioni più dirette. Un provider dedicato può semplificare la configurazione ed evitare sovraccarichi. I servizi come Ambienti di distribuzione di Azure o Terraform Cloud sono più direttamente incentrati sull'abilitazione del provisioning basato su modelli IaC e in modo sicuro e sicuro. Altri esempi possono includere elementi come la creazione di spazi dei nomi Kubernetes per le applicazioni in cluster condivisi o l'uso di Git con flussi di lavoro GitOps usando Flux o Argo CD come tipo specifico di provider. Ancora più modelli incentrati sulle app come il progetto di incubazione RADIUS OSS sperimentale con le proprie CLI potrebbero avere i propri provider di piattaforme per sviluppatori nel tempo. La cosa chiave è cercare e pianificare l'estendibilità in modo da poter adattare.
Scaffolding/seeding dell'applicazione	I modelli di applicazione sono una parte importante della posizione in cui la progettazione della piattaforma conduce nel tempo. È possibile supportare il motore di template preferito fornendo un provider di piattaforma per sviluppatori dedicato e progettato non solo per creare la struttura di un albero del codice sorgente dell'applicazione, ma anche per creare e inserire contenuti in un repository di codice sorgente e aggiungere le entità risultanti al grafico. Ogni ecosistema ha le proprie preferenze di impalcatura delle applicazioni, sia che si tratti di Yeoman, cookiecutter o di qualcosa come l'interfaccia a riga di comando per sviluppatori di Azure, quindi il modello di provider qui può consentire di supportare più opzioni dalle stesse interfacce. Anche in questo caso, è l'estendibilità chiave.
Processi manuali	Indipendentemente dal fatto che venga generata automaticamente una o più richieste pull per l'approvazione manuale o che gli utenti non sviluppatori debbano interagire con un flusso di lavoro manuale tramite piattaforme come Power Platform, lo stesso modello basato su template può essere utilizzato in un provider di piattaforme per sviluppatori. È anche possibile passare a passaggi più automatizzati nel tempo.

Anche se potrebbe non essere necessario avviare tutti questi provider, è possibile vedere come l'estendibilità tramite un provider di piattaforme per sviluppatori può aiutare le funzionalità di automazione a crescere nel tempo.

Utenti e team

La progettazione della piattaforma è intrinsecamente una questione multi-sistema, quindi è importante pianificare come una base self-service deve gestire i problemi più complessi con l'integrazione di questi sistemi insieme. Ecco una strategia per affrontare le sfide comuni con identità, utenti e team.

Raccomandazione	Description
Integrare l'API della piattaforma per sviluppatori direttamente con il provider di identità per garantire una sicurezza ottimale.	Per proteggere l'API della piattaforma per sviluppatori, è consigliabile utilizzare l'integrazione diretta con un provider di identità come Microsoft Entra ID, data la robusta identità e le funzionalità di controllo degli accessi in base al ruolo dell'ID Entra. Esistono molti vantaggi per l'uso diretto degli SDK nativi e delle API di un provider di identità ,ad esempio tramite MSAL Entra ID, anziché tramite un'astrazione. È possibile implementare la sicurezza end-to-end e fare affidamento sullo stesso modello di controllo degli accessi in base al ruolo in modo costante, assicurando al contempo che i criteri di accesso condizionale vengano continuamente valutati (anziché solo al momento dell'accesso).
Utilizza le integrazioni per i gruppi di fornitori di identità e il single sign-on nei sistemi downstream.	Le integrazioni di Single Sign-On (SSO) devono usare lo stesso provider di identità e lo stesso tenant usato per l'API della piattaforma per sviluppatori. Assicurarsi anche di sfruttare qualsiasi supporto per protocolli come SCIM per collegare i gruppi di provider di identità (ad esempio i gruppi di AD). L'associazione di questi gruppi di provider di identità alle autorizzazioni di sistema downstream non è sempre automatica, ma almeno, è possibile associare manualmente i gruppi di provider ai concetti di raggruppamento di ogni strumento senza gestire manualmente l'appartenenza in un secondo momento. Ad esempio, è possibile combinare il supporto emu ( Enterprise Managed User ) di GitHub e sfruttare manualmente la possibilità di associare i gruppi di provider di identità ai team di GitHub. Azure DevOps offre funzionalità simili.

Definire il concetto di team che vada oltre un singolo gruppo di fornitori di identità

Man mano che il percorso di ingegneria della piattaforma continua, è probabile che i gruppi di fornitori di identità siano ideali per la gestione dell'appartenenza, ma che più gruppi debbano davvero unirsi per formare il concetto di team per il controllo degli accessi basato sui ruoli e l'aggregazione dei dati.

Nel contesto dell'ingegneria della piattaforma, definiamo un team come gruppo di persone in ruoli diversi che lavorano insieme. Per l'aggregazione dei dati, l'idea di un team multi-ruolo è fondamentale per l'individuazione e la sintesi delle informazioni nelle dashboard di reportistica. D'altra parte, un gruppo è un concetto generale di provider di identità per un set di utenti ed è progettato con l'idea di aggiungere più persone a un ruolo specifico, anziché in altro modo. Con il controllo degli accessi in base al ruolo, un team può quindi collegarsi a più gruppi di fornitori di identità tramite ruoli diversi.

L'origine dei dati del team può provenire da alcune posizioni diverse. Ad esempio, se si utilizza il modello teams as code (TAC), un provider della piattaforma per sviluppatori può monitorare le modifiche dei file in un repository e memorizzarle nella cache in un profilo utente e nello store dei metadati del team. In alternativa, è possibile integrarsi direttamente con un progetto di Azure Dev Center che già dispone di questi principali costrutti di RBAC (controllo degli accessi basato sui ruoli) disponibili.

Stabilire un modello per l'integrazione con sistemi downstream a livello di team o utente

Anche se alcuni strumenti e servizi DevOps si integrano nativamente e utilizzano direttamente i concetti del fornitore di identità, molti astraggono tutto questo nella propria rappresentazione di un gruppo o di un utente (anche con SSO). Oltre ad abilitare l'accesso tra gli strumenti, questa realtà può anche causare problemi per l'aggregazione dei dati. In particolare, è possibile che le API nel sistema downstream usino i propri identificatori anziché gli identificatori del provider di identità ( ad esempio, l'ID oggetto in Entra ID non viene usato direttamente). Ciò rende difficile filtrare e associare i dati a livello di utente o team, a meno che non sia possibile eseguire il mapping tra ID diversi.

Risolvere le differenze tra team e livello di gruppo

I modelli come TaC consentono di archiviare e accedere alle relazioni tra i team o gli identificatori di gruppo di ogni sistema in modo che sia possibile eseguirne il mapping. Per riepilogare, un repository Git sicuro e verificabile diventa la fonte principale per un team e le Pull Requests (PR) forniscono un'interfaccia utente controllata per eseguire gli aggiornamenti. I sistemi CI/CD possono quindi aggiornare i sistemi downstream e mantenere le relazioni tra identificatori correlati per il team che li ha utilizzati.

Ciò consente, ad esempio, di archiviare le relazioni seguenti per nelle chiamate API:

Se si preferisce usare un'origine dati diversa dai file in un repository, i team possono applicare lo stesso concetto generale usando l'agente di orchestrazione della piattaforma per sviluppatori per eseguire la stessa operazione. In questo modello, un provider di piattaforme per sviluppatori per l'origine dei dati del team può attivare un evento di aggiornamento del team che tutti gli altri provider ricevono e agiscono in base alle esigenze.

Risolvere i problemi relativi all'ID utente

Un'altra sfida correlata per l'accesso ai dati e l'aggregazione è costituita dalle differenze tra ID utente. Come nel caso del team, se si usa un'integrazione da sistema a sistema per eseguire query sui dati relativi a un utente, non è possibile presupporre che l'ID nativo dei provider di identità (ad esempio, ID oggetto per Entra ID) supporti una determinata API. Anche in questo caso, l'archiviazione di un mapping per un ID utente che accede ai dati tramite l'API della piattaforma per sviluppatori può essere utile. Si consideri ad esempio GitHub:

Per ogni sistema, se è possibile eseguire una ricerca di un ID utente in un altro sistema tramite un'API senza un token utente, un determinato provider di piattaforme per sviluppatori può generare questo mapping in tempo reale. In alcuni casi, questo può risultare complicato perché potrebbe essere necessario eseguire questa operazione in blocco e memorizzare nella cache i risultati per fare riferimento a mantenere le prestazioni.

Ricorrere all'uso di più token utente

Per situazioni in cui i provider devono accedere ai dati a livello di utente senza un modo per eseguire la conversione degli ID utente che funzionerebbe, l'API della piattaforma per sviluppatori può essere configurata per gestire più token utente. Per esempio:

• L'API della piattaforma per sviluppatori può supportare una cache di token utente specifici del provider da usare con i sistemi downstream.
• Eventuali interazioni con un determinato provider attivate dall'API includerebbero il token utente del provider, se disponibile.
• Per gestire il caso in cui non fosse disponibile alcun token utente, il provider attiverà un flusso OAuth per ottenerlo.
• Per iniziare, l'API della piattaforma per sviluppatori passerebbe di nuovo un URI di autenticazione per un flusso OAuth con un URI di reindirizzamento passato al provider. L'URI passato include un codice nonce/monouso.
• L'API restituisce quindi una risposta non autenticata con l'URI.
• Qualsiasi esperienza utente può quindi usare questo URI per guidare il flusso di autenticazione appropriato in un browser.
• Una volta eseguito il reindirizzamento, la piattaforma per sviluppatori riceverà il token utente necessario e la memorizza nella cache per riferimento futuro insieme all'ID utente.
• Il client potrebbe quindi ritentare la chiamata API, che avrà esito positivo.

Questo concetto descrive un modo per gestire l'autenticazione complessa perché è possibile riutilizzare gli ID laddove possibile e non è necessario mantenere URI di reindirizzamento separati per ogni sistema downstream.

Usare collegamenti diretti con riconoscimento del contesto agli strumenti e ai sistemi di creazione di report

Fino a questo punto abbiamo parlato dell'aspetto di automazione dello spazio del problema. Questo solo può andare molto lontano perché l'interfaccia utente può usare i valori nelle entità restituite durante l'automazione per creare collegamenti diretti in altri sistemi per il team.

Anche quando non sono correlati all'automazione, i provider di piattaforme per sviluppatori possono generare qualsiasi tipo di entità necessaria. Tuttavia, in genere non si vogliono inserire tutti i dati dettagliati nell'intera piattaforma di sviluppo interna nel grafico della piattaforma per sviluppatori. I dashboard nelle soluzioni di osservabilità come Grafana, Prometheus, DataDog, l'intelligence del codice in prodotti come SonarQube e le capacità native nelle suite DevOps come GitHub e Azure DevOps, sono tutte funzionalità potenti. Al contrario, l'approccio migliore consiste spesso nel creare collegamenti diretti in questi altri sistemi. Le entità possono fornire informazioni sufficienti per creare collegamenti senza contenere direttamente informazioni dettagliate, ad esempio il contenuto del log.

Per i casi in cui si vogliono aggregare e riepilogare i dati tra gli strumenti o è necessario guidare metriche personalizzate, le soluzioni di creazione di report Power BI o Microsoft Fabric possono essere la prossima porta di chiamata. Per unire i dati del team, è possibile connettersi al database della fondazione o passare attraverso un'API della piattaforma per sviluppatori. Ad esempio, come descritto in Pianificare e classificare in ordine di priorità, un'area in cui si potrebbe desiderare un dashboard personalizzato è per misurare il successo della piattaforma interna per sviluppatori.

Essere selettivi con ogni esperienza aggiuntiva creata

Anche se può essere interessante ricreare le funzionalità esistenti in un portale comune, tenere presente che sarà necessario gestirle. Questa è l'area in cui è importante seguire una mentalità orientata al prodotto. Le interfacce in stile dashboard sono facili da concepire e comprendere, ma gli sviluppatori potrebbero trovare più valore altrove.

Detto questo, il modello qui consente di usare i dati aggregati nel grafico della piattaforma per sviluppatori per creare esperienze utente personalizzate. Le entità devono disporre del supporto predefinito in modo che possano collegarsi a un utente o a un team. In questo modo, l'API della piattaforma per sviluppatori può definire l'ambito dell'output ,insieme all'uso dell'indicizzazione e della memorizzazione nella cache.

Tuttavia, anche quando è necessario creare un'esperienza utente personalizzata anziché un collegamento diretto, il pull di tutti i dati nel grafico della piattaforma per sviluppatori non è in genere l'approccio migliore. Si consideri, ad esempio, una situazione in cui si desidera visualizzare i registri nell'interfaccia utente che dispone già di una pagina principale ben definita e gestita. Usare le informazioni nelle entità correlate per consentire all'esperienza utente di raccogliere informazioni direttamente dai sistemi downstream.

Per iniziare potrebbe essere necessario usare un'integrazione da sistema a sistema per connettersi, ma dopo aver implementato uno dei modelli descritti in utenti e team, è possibile usare qualsiasi ID utente/team archiviato o token di autenticazione utente, se necessario.

Ecco alcuni esempi di esperienze comuni da considerare:

Example	Description
Individuazione ed esplorazione	Come ha detto un professionista dell'ingegneria delle piattaforme, "Ciò che rallenta i progetti è la comunicazione, non le competenze degli sviluppatori." –Daniel, Ingegnere Cloud, azienda Fortune 500 del settore media. Poiché il software è uno sport di squadra, la creazione di un'interfaccia utente per individuare i team e le entità di cui sono proprietari sono in genere una delle prime cose da affrontare. La ricerca, l'individuazione e la documentazione tra team aiutano a promuovere il riutilizzo e facilitano la collaborazione per l'approvvigionamento o il supporto interno. Teams trae vantaggio anche dalla possibilità di avere un unico punto vendita per trovare elementi di cui sono proprietari, inclusi ambienti, repository e altre risorse come la documentazione.
Registrazione manuale di ambienti o risorse	Anche se è possibile effettuare il provisioning e tenere traccia di molti elementi tramite l'agente di orchestrazione della piattaforma per sviluppatori, è anche possibile registrare risorse o ambienti già esistenti o non ancora automatizzati. Un provider semplice che acquisisce informazioni da un repository Git e aggiunge informazioni nella gestione delle risorse/dell'ambiente può essere utile qui. Se si dispone già di un catalogo software, questo diventa anche un modo per integrarlo nel modello.
Un catalogo API	Le API di rilevamento che gli sviluppatori devono usare possono andare molto lontano. Se non si dispone già di qualcosa, è anche possibile iniziare con un semplice repository Git con una serie di file che rappresentano le API, il relativo stato, per gestire il flusso di lavoro di approvazione usando le pull request. Questi elementi possono essere aggiunti nel grafico della piattaforma per sviluppatori in modo che possano essere visualizzati o associati ad altre entità. Per funzionalità più affidabili, è possibile integrare qualcosa come il Centro API Microsoft o un altro prodotto.
Conformità della licenza	In alcuni casi, è anche possibile fornire visibilità sulla conformità delle licenze software e sul consumo di licenze. Le piattaforme per sviluppatori possono anche aggiungere l'automazione necessaria per consumare le licenze, ma anche nel caso in cui le licenze vengano assegnate manualmente (ad esempio, tramite un processo pull request in un repository Git), la visibilità degli sviluppatori su ciò che possiedono (e la possibilità per l'amministratore di avere una visione completa).
Visualizzazione incentrata sulle applicazioni di Kubernetes	Quando si usa un cluster Kubernetes condiviso, può essere difficile per gli sviluppatori trovare e comprendere lo stato delle applicazioni tramite l'esperienza utente amministratore del cluster. Diverse organizzazioni potrebbero scegliere di gestire questo problema in modo diverso, ma l'uso di uno spazio dei nomi per rappresentare un'applicazione è un modo noto per farlo. Da qui è possibile usare le entità per stabilire associazioni tra lo spazio dei nomi dell'applicazione nel cluster e un team e creare una visualizzazione più mirata dello stato dello sviluppatore per l'applicazione e fornire collegamenti diretti ad altri strumenti o interfacce utente Web.

Esperienze degli utenti

Diversi ruoli dell'organizzazione hanno strumenti o servizi che rappresentano un centro di gravità per il lavoro quotidiano. L'attrazione di questi sistemi può rendere difficile per le nuove esperienze utente al di fuori di questi centri di gravità affermarsi. In un mondo perfetto, gli sviluppatori, le operazioni e altri ruoli possono continuare a lavorare in un ambiente che ha senso per loro, spesso quelli già in uso.

Tenendo presente questo aspetto, la pianificazione di più interfacce utente durante il percorso di progettazione della piattaforma è una buona idea. Questo può anche offrire un'opportunità per iniziare semplici, dimostrare valore e crescere verso interfacce più complesse in base alle esigenze.

Integra quello che hai

Se sono stati letti gli articoli Applicare sistemi di progettazione software e Perfezionare la piattaforma delle applicazioni , è probabile che siano stati identificati i sistemi da continuare a usare. In entrambi i casi, valutare se è possibile migliorare ed estendere ciò che si ha prima di iniziare a creare nuove esperienze da zero. (Chiediti, le persone reagiscono meglio a un'altra nuova esperienza utente o a una versione migliorata di qualcosa che hanno ora?)

Alcuni degli strumenti, delle utilità o delle app Web che si desidera continuare a usare saranno personalizzati e questi sono buoni candidati per migliorare. Ma non dimenticare di prestare attenzione a se gli strumenti e i servizi preferiti hanno un modello di estendibilità che è possibile usare. Otterrai molti benefici iniziando da lì. Questo può eliminare i problemi di manutenzione e sicurezza e consentire di concentrarsi sul problema che si sta cercando di risolvere

Ad esempio, potrebbe essere possibile estendere le superfici seguenti già in uso:

• Editor e IDE
• La famiglia di prodotti DevOps
• Anche le interfacce CLI sono sempre più estendibili
• Ambienti con poco codice, ad esempio Power Pages

Ognuno può fornire un punto di partenza migliore per un determinato ruolo rispetto a quello configurato da zero, poiché sono centri di gravità esistenti. La presenza di un'API della piattaforma per sviluppatori comune come baseline consente di scambiare elementi, sperimentare e cambiare nel tempo.

Prendere in considerazione le estensioni dell'editor Web per creare un portale per sviluppatori

Se si sta cercando un'esperienza basata sul Web per gli sviluppatori, tenere presente che una tendenza recente è costituita da versioni basate sul Web di editor e IDE. Molti, come quelli che usano VS Code, hanno il supporto dell'estensione. Con VS Code, tutto ciò che si crea per queste esperienze Web viene quindi convertito in locale per un doppio vantaggio.

Oltre ai servizi come GitHub Codespaces, vscode.dev è una versione Web gratuita dell'editor di VS Code senza calcolo, ma include il supporto per determinati tipi di estensioni , incluse quelle che usano webview per l'interfaccia utente personalizzata.

Anche se gli sviluppatori non usano VS Code, i modelli di esperienza utente sono ben noti e sono disponibili in altri strumenti di sviluppo. L'uso di vscode.dev può fornire una base pratica e familiare basata sul Web per le esperienze di sviluppo oltre allo strumento stesso.

Questi possono fungere da portale incentrato sullo sviluppatore in un formato familiare che può anche adattarsi all'uso locale.

ChatOps

Un'altra opportunità spesso trascurata consiste nell'implementare un'interfaccia ChatOps. Dato l'aumento delle interfacce basate su chat a causa dell'aumento dei prodotti di intelligenza artificiale come ChatGPT e GitHub Copilot, i comandi di azione o i comandi barra possono offrire un modo utile per attivare flussi di lavoro di automazione, controllare lo stato e altro ancora. Dato che la maggior parte delle piattaforme CI/CD applicative offre supporto integrato per sistemi come Microsoft Teams, Slack o Discord, questo può essere un modo naturale per integrarsi con altre interfacce utente che sviluppatori e ruoli operativi correlati utilizzano quotidianamente. Inoltre, tutti questi prodotti hanno un modello di estendibilità.

Investire in un nuovo portale per sviluppatori

Supponendo di non avere un portale o un'interfaccia esistente che si vuole usare come base, è possibile decidere di creare un nuovo portale per sviluppatori. Si pensi a questo come destinazione anziché a un punto di partenza. Se non hai già un team di sviluppo che collabora con te, iniziare questa operazione è il momento giusto. Ogni organizzazione è diversa, quindi non c'è una risposta universale per ciò che dovrebbe essere in questo tipo di esperienza. Di conseguenza, non esiste una risposta predefinita per un prodotto preconfezionato che è possibile attivare e usare as-is per qualcosa di simile a questo oggi.

Per opzioni self-hosted personalizzate costruite su misura, i framework generali dei portali web non sono una novità, e i team di sviluppo potrebbero già utilizzarne uno. Se stai cercando di presentare qualcosa agli utenti per un feedback iniziale, è anche possibile iniziare con qualcosa di semplice come il low-code Power Pages per connettersi all'API della comune piattaforma per sviluppatori.

Gli interventi più recenti sui portali sviluppatori sono più caratterizzati. Ad esempio, Backstage.io è un toolkit del portale per sviluppatori personalizzato creato inizialmente per soddisfare le esigenze di Spotify. Include un'interfaccia della riga di comando per eseguire il bootstrap dell'albero di origine in modo molto simile a create-react-app per React.js.

Come toolkit del portale, è necessario lavorare per iniziare e personalizzare richiede la conoscenza di TypeScript, Node.js e React. Tuttavia, la cosa importante è che, come toolkit, è possibile cambiare quasi qualsiasi cosa. Ha anche un proprio catalogo software e meccanismo di creazione di modelli, ma il loro uso non è necessario, ed è un modo ben definito per inserire nuovo codice denominato plug-in.

Contenuti correlati

• Microsoft Power Pages
• Backstage.io
• Applicare sistemi di progettazione software