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 di seguito, 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 self-service con protezioni tramite l'esecuzione e il provisioning di attività controllati e regolamentati, 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 dovranno cambiare. Il problema principale è che gli standard sono una destinazione mobile. Come affermato da un professionista dell'ingegneria della piattaforma:

Le difficoltà comportano la standardizzazione ... e trattando di 'abandonware'... 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, DevOps Engineer, Large Logistics Company

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 abilitare 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 [Dati] è secondaria. – Peter, platform engineering Lead, Multinazionale Tech company

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 creare interfacce CLI, pagine Web di base o anche Power Pages, Power BI o dashboard di 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:

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 consente di pensare a cosa dovrebbe essere una base come questa dovrebbe essere in grado di eseguire al termine. 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é lo sviluppo dei clienti 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 usata da interfacce utente diverse per abilitare l'accesso ai dati o il provisioning delle unità 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à primari. Per altre informazioni, vedere Utenti e team.

Provider di piattaforme per sviluppatori

Data l'ampiezza di una piattaforma per sviluppatori interna, 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, le attività di approvvigionamento interno per la progettazione della piattaforma non riescono a ottenere trazione a causa di sfide con la manutenzione in corso. 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

Entità

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:

• Surfacing externally provisioning resources/environments or available APIs for discovery and use (Esplora risorse/ambienti con provisioning esterno o API disponibili per l'individuazione e l'uso)
• Esposizione di relazioni per l'analisi delle dipendenze, l'analisi dell'impatto, l'individuazione e così via.
• Surfacing maintainer/ownership information for discovery and collaboration
• 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 ci si dirige verso il basso, è qualcosa da pensare a 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
• Provider di origine
• Associazioni facoltative per:
  • utente proprietario
  • Team proprietario
  • 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. La creazione di controllo degli accessi in base al ruolo fin dall'inizio è fondamentale per la sicurezza e la crescita della piattaforma per sviluppatori interna nel tempo. Dato lo sviluppo è uno sport di team, scoprire chi parlare di un'entità diventerà rapidamente fondamentale per riutilizzare, supportare e innersourcing.

Entità comuni e specifiche del provider

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

• Ambienti
• Risorse
• API
• Repository
• Componenti
• Strumenti

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

Altri saranno 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 che il sistema o l'utente specificato, necessari per eseguire l'azione. Questi valori possono variare da qualsiasi elemento, ad esempio la denominazione della risorsa alle aggiunte facoltative.

Esempi di modelli includono:

• Modelli IaC (Infrastructure-as-Code)
• 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 con parametri di Power Automate (ad esempio: 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 può 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 repository, registri o cataloghi diversi. 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 stessi possono essere ospitati nella posizione più naturale 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 di creare protezioni che consentono di applicare la conformità agli standard o ai criteri dell'organizzazione. Altre informazioni su questo argomento quando si tratta dell'agente di orchestrazione della piattaforma per sviluppatori in un po'.

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 salvati in modo permanente direttamente in un database specifico del grafo. Al contrario, le interazioni con i provider potrebbero essere memorizzate nella cache insieme ai metadati necessari per renderle tutte insieme.

Il grafico è potente quando usato con entità comuni che più provider possono contribuire. 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 attività, un motore del flusso di lavoro o un altro agente di orchestrazione a tale scopo. È uno dei componenti critici che si vuole essere sicuri sia una parte delle basi 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 INTEGRAZIONE continua o distribuzione continua, 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 eseguire la migrazione nel tempo o semplicemente l'uso del nuovo motore a nuove azioni senza influire su quelli meno recenti.
• 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 l'esecuzione di un elemento in grado di supportare GitHub Actions o Azure Pipelines non è necessario o conveniente 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 eseguirà 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/aggiornare nel grafico della piattaforma per sviluppatori. Possono trattarsi di entità specifiche del provider o comuni.

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, le operazioni o altri membri del team di progettazione della 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'agente di orchestrazione fino al completamento. 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 esegue. È possibile aggiungerli nel tempo in base alle esigenze.

Gran parte di quanto descritto in questo esempio applica il funzionamento di altri tipi di provider. È anche importante notare che l'uso di GitHub Actions o Azure Pipelines in questo contesto non richiede l'uso anche per le pipeline CI/CD effettive.

Altri esempi

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

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.

Definire il concetto di team oltre un singolo gruppo di provider di identità

Man mano che il percorso di progettazione della piattaforma continua, è probabile che i gruppi di provider di identità siano ideali per la gestione dell'appartenenza, ma che più gruppi devono davvero riunirsi per formare il concetto di team per il controllo degli accessi in base al ruolo 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 il rollup delle informazioni in posizioni come i dashboard di creazione di report. 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 essere correlato a più gruppi di provider di identità tramite ruoli diversi.

L'origine dei dati del team può provenire da alcune posizioni diverse. Ad esempio, se si usano i team come modello di codice (TaC), un provider della piattaforma per sviluppatori può controllare le modifiche dei file in un repository e memorizzarle nella cache in un profilo utente e nell'archivio dei metadati del team. In alternativa, è possibile integrarsi direttamente con un progetto di Azure Dev Center che dispone già di questi costrutti di controllo degli accessi in base al ruolo principali disponibili.

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

Anche se alcuni strumenti/servizi per sviluppatori e operazioni si integrano in modo nativo e usano direttamente i concetti del provider di identità, molti lo astrarranno 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 controllabile diventa l'origine di un team e le richieste pull forniscono un'interfaccia utente controllata per eseguire gli aggiornamenti. I sistemi CI/CD possono quindi aggiornare i sistemi downstream e rendere persistenti le relazioni tra identificatori correlati per il team usato per farlo.

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 di 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.

Eseguire il fallback usando 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. Ad esempio:

• L'API della piattaforma per sviluppatori può supportare una cache di token utente specifici del provider da usare con sistemi downstream.
• Eventuali interazioni con un determinato provider attivato dall'API includerebbero nel 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 o intelligence sul codice in prodotti come SonarQube e funzionalità native nelle suite DevOps come GitHub e Azure DevOps sono tutti molto capaci. 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 di Foundation o passare tramite un'API della piattaforma per sviluppatori. Ad esempio, come descritto in Pianificare e classificare in ordine di priorità, un'unica posizione in cui si potrebbe volere un dashboard personalizzato sta misurando il successo della piattaforma per sviluppatori interna.

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 di stile del 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 è possibile visualizzare i log nell'esperienza utente che dispone già di una casa 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:

Esperienze degli utenti

Diversi ruoli dell'organizzazione hanno strumenti o servizi che rappresentano un centro di gravità per il lavoro quotidiano. Il pull di questi sistemi può rendere difficile per le nuove esperienze utente al di fuori di questi centri di gravità per ottenere trazione. In un mondo perfetto, gli sviluppatori, le operazioni e altri ruoli possono continuare a lavorare in un ambiente appropriato, 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.

Integrare ciò che si ha

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. Si otterrà un sacco di vantaggi dall'avvio. 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 consentirà 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 , inclusi quelli che usano webview per l'interfaccia utente personalizzata.

Anche se gli sviluppatori non usano VS Code, i modelli di esperienza utente sono 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 tradurre in 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 dell'applicazione ha supporto predefinito per sistemi come Microsoft Teams, Slack o Discord, questo può essere un modo naturale per integrarsi con altri sviluppatori di interfacce utente e i ruoli operativi correlati usano ogni giorno. 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 si ha già un team di sviluppo che collabora con l'utente, iniziare questa operazione è il momento necessario. Ogni organizzazione è diversa, quindi non c'è una risposta adatta a tutte le dimensioni per ciò che dovrebbe essere in questo tipo di esperienza. Di conseguenza, non c'è alcuna risposta defacto per un prodotto preconfezionato che è possibile attivare e usare così come è per qualcosa come questo oggi.

Per le opzioni self-hosted personalizzate, i framework generali del portale Web non sono nuovi e i team di sviluppo potrebbero già usare uno di essi. Se si sta provando a ottenere qualcosa davanti agli utenti per un feedback anticipato, è anche possibile iniziare con qualcosa di semplice come Power Pages a basso codice per connettersi all'API della piattaforma per sviluppatori comune.

Gli sforzi più recenti del portale per sviluppatori sono più opinioni. 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 una 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, e ha un modo ben definito per inserire il nuovo codice di 1^st e 3^rd party denominato plugins.

Contenuto correlato

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