Applicare sistemi di progettazione software

Il miglioramento del self-service per gli sviluppatori dev'essere uno dei primi problemi da affrontare nel percorso di ingegneria della piattaforma.

Uno dei modi più semplici per iniziare ad abilitare esperienze self-service automatizzate consiste nel riutilizzare i sistemi di progettazione esistenti. Non solo questi sistemi hanno familiarità con l'utente e i clienti interni, ma possono abilitare un'ampia gamma di scenari di automazione anche se l'esperienza utente iniziale non è bella.

Questo articolo fornisce suggerimenti per l'applicazione dei sistemi di ingegneria per affrontare una gamma più ampia di scenari self-service e dettagli su come racchiudere le procedure consigliate nei modelli che consentono di iniziare correttamente e restare sul giusto percorso.

Valutare le procedure DevOps e DevSecOps di base

I sistemi di progettazione sono un aspetto fondamentale della piattaforma per sviluppatori interna. Le piattaforme di sviluppo interne si basano sui tenant principali di DevOps e DevSecOps per ridurre il carico cognitivo per tutti gli utenti coinvolti.

DevOps combina lo sviluppo e le operazioni per unire persone, processi e tecnologie nella pianificazione delle applicazioni, sviluppo, distribuzione e operazioni. Ha l'obiettivo di migliorare la collaborazione tra ruoli storicamente a silos come lo sviluppo software, le operazioni IT, l'ingegneria della qualità e la sicurezza informatica. Si stabilisce un ciclo continuo tra sviluppo, distribuzione, monitoraggio, osservazione e feedback. DevSecOps si integra in questo ciclo con pratiche di sicurezza continue durante il processo di sviluppo delle applicazioni.

Le sezioni seguenti riguardano i miglioramenti più direttamente attribuiti allo spostamento della progettazione della piattaforma: percorsi pavimentati, provisioning automatizzato dell'infrastruttura (oltre alla distribuzione dell'applicazione), configurazione dell'ambiente di codifica, oltre al provisioning self-service e alla configurazione di strumenti, asset del team e servizi che non fanno parte direttamente del ciclo di sviluppo dell'applicazione.

Stabilire i percorsi pavimentati desiderati

Se si dispone di più set di strumenti che costituiscono già i sistemi di progettazione, una decisione iniziale da prendere è se si vuole consolidarle come parte delle attività iniziali di progettazione della piattaforma o se si supporterà una costellazione di strumenti diversi fin dall'inizio. La definizione di un set di percorsi pavimentati all'interno di questa costellazione di strumenti è più efficace e offre un maggiore livello di flessibilità.

Quando si inizia a passare a una mentalità orientata ai prodotti, considerare i sistemi di progettazione all'interno di questi percorsi pavimentati come costituiti da strumenti gestiti centralmente come servizio ai team di sviluppo. I singoli team o divisioni all'interno dell'organizzazione possono quindi deviare dalle linee guida, ma è previsto che gestiscano, mantengano e paghi separatamente i propri strumenti e rispettare i requisiti di conformità. In questo modo è possibile inserire nuovi strumenti nell'ecosistema senza interruzioni, poiché è possibile valutare qualsiasi elemento che devia per la possibile inclusione in un percorso pavimentato nel tempo. Come ha affermato un responsabile dell'ingegneria della piattaforma:

Puoi ancora perseguire i tuoi obiettivi, ma fallo nella direzione in cui ci stiamo muovendo... è possibile cambiare quello che vuoi, ma questo diventa la tua responsabilità. Hai il controllo dei cambiamenti – hai in mano coltelli affilati. - Mark, responsabile ingegneria della piattaforma, grande società multinazionale europea al dettaglio

Dato che un obiettivo chiave per l'ingegneria della piattaforma è passare a una mentalità orientata ai prodotti in cui si fornisce valore ai clienti interni, questo approccio costellazione funziona in genere meglio di un mandato dall'alto verso il basso. Quando si stabiliscono e si affinano i percorsi pavimentati, lasciando una certa flessibilità, i team possono fornire input e soddisfare qualsiasi requisito veramente univoco per una determinata applicazione senza influire sugli altri utenti dell'organizzazione. Questo porta a una serie di percorsi completamente pavimentati, dorati, mentre altri sono solo parzialmente pavimentati. Nei casi in cui non ci sono requisiti univoci, il lavoro aggiuntivo di sviluppo che i team intraprendono naturalmente li porta a voler passare nel tempo a un percorso supportato.

Se si preferisce una strategia di consolidamento, la migrazione delle applicazioni esistenti potrebbe richiedere più lavoro di quanto si pensi. Pertanto, inizialmente si potrebbe voler focalizzare l'attenzione sull'avvio nel modo giusto in questo ambito e concentrarsi su nuovi progetti. Questo fornisce il primo percorso pavimentato, mentre tutto quello che esiste è intrinsecamente non pavimentato. I team di sviluppo nel percorso non aperto possono quindi prendere in considerazione la possibilità di spostarsi dopo che il nuovo percorso aperto mostra il suo valore all'organizzazione. A questo punto è possibile eseguire una campagna di allineamento per portare tutti sullo stato desiderato attraverso una comunicazione bidirezionale, dal momento che i team di sviluppo la considerano un vantaggio anziché un'imposta. Durante la campagna, i team di progettazione della piattaforma possono concentrarsi sulla migrazione dei team, mentre i team di sviluppo forniscono feedback su come migliorare i percorsi pavimentati.

Indipendentemente da ciò, evitare di imporre l'uso dei percorsi pavimentati. Il modo più efficace per implementare i percorsi pavimentati consiste nel sottolineare i vantaggi che i team ne ricavano, piuttosto che attraverso l'adozione forzata. Poiché la piattaforma interna per sviluppatori è incentrata sul rendere felici proprio questi team, il budget e la pressione del tempo per ottenere valore sui singoli leader si prendono cura del resto. Implementa campagne adeguate, quindi fornisci un canale per dialoghi bidirezionali sul modo migliore per coloro che si trovano su un percorso non asfaltato di passare alla nuova modalità.

Usare gli strumenti di automazione per sviluppatori per migliorare il self-service per i percorsi pavimentati

Parte della creazione del primo percorso pavimentato dovrebbe essere quello di stabilire i prodotti di automazione per sviluppatori di base. Questi sono importanti quando si inizia a pensare all'abilitazione delle funzionalità self-service dello sviluppatore.

Abilitare il provisioning automatico dell'infrastruttura dell'applicazione durante l'implementazione continua

Se non è già stato implementato, i problemi identificati durante la pianificazione indicano probabilmente problemi che l'integrazione continua (CI) e il recapito continuo (CD) possono contribuire a risolvere. In questo spazio esistono prodotti come GitHub Actions, Azure DevOps, Jenkins, insieme a soluzioni GitOps basate sul pull, come Flux o Argo CD . È possibile iniziare a usare questi argomenti nel Centro risorse Microsoft DevOps.

Anche se hai già implementato un modo per distribuire continuamente l'applicazione nell'infrastruttura esistente, dovresti prendere in considerazione l'uso di infrastruttura come codice (IaC) per creare o aggiornare l'infrastruttura necessaria dell'applicazione come parte della pipeline CD.

Si considerino ad esempio le illustrazioni seguenti che illustrano due approcci che usano GitHub Actions per aggiornare l'infrastruttura e distribuirla nel servizio Azure Kubernetes: una con distribuzioni basate su push e una distribuzione basata su pull (GitOps).

La scelta dipende dal set di competenze IaC esistente e dai dettagli della piattaforma dell'applicazione di destinazione. L'approccio GitOps è più recente ed è diffuso tra le organizzazioni che usano Kubernetes come base per le applicazioni, mentre il modello basato sul pull offre attualmente la massima flessibilità in base al numero di opzioni disponibili. Ci aspettiamo che la maggior parte delle organizzazioni usi una combinazione dei due. Indipendentemente dalla buona conoscenza delle procedure IaC, è possibile apprendere i modelli che si applicano ad altri scenari di automazione.

Centralizzare IaC in un catalogo o registro per ridimensionare e migliorare la sicurezza

Per gestire e ridimensionare IaC nelle applicazioni, dovresti pubblicare in modo centralizzato gli artefatti IaC per il riutilizzo. Ad esempio, è possibile usare i moduli Terraform in un registro, moduli Bicep, ricette Radius o grafici Helm archiviati in un registro OCI Artifact nativo del cloud, ad esempio Registro Azure Container,DockerHub o il catalogo in Ambienti di distribuzione di Azure . Per GitOps e Kubernetes, l'API cluster (e le implementazioni come CAPZ) consente di gestire i cluster del carico di lavoro Kubernetes, mentre le definizioni di risorse personalizzate come l'operatore del servizio di Azure possono fornire supporto aggiuntivo per altri tipi di risorse di Azure. Altri strumenti, ad esempio crossplane, supportano le risorse in più cloud. In questo modo è possibile utilizzare i chart Helm centralizzati o comuni nel registro Azure Container (ACR) per una gamma più ampia di scenari.

La centralizzazione di IaC migliora la sicurezza offrendo un migliore controllo sugli utenti che possono apportare aggiornamenti perché non vengono più archiviati con il codice dell'applicazione. È minore il rischio di interruzione accidentale causata da una modifica accidentale durante un aggiornamento del codice quando esperti, operazioni o tecnici della piattaforma apportano modifiche necessarie. Gli sviluppatori traggono vantaggio anche da questi blocchi predefiniti perché non devono creare modelli IaC completi e trarre automaticamente vantaggio dalle procedure consigliate codificate.

Il formato IaC scelto dipende dal set di competenze esistente, dal livello di controllo necessario e dal modello di app usato. Ad esempio, Azure Container Apps (ACA) e il recente progetto di incubazione Radius OSS sperimentale sono più definiti rispetto all'uso diretto di Kubernetes, ma semplificano anche l'esperienza dello sviluppatore. Per informazioni sui vantaggi e sui svantaggi di modelli diversi, vedere Descrivere i tipi di servizio cloud. Indipendentemente da ciò, fare riferimento a IaC centralizzato e gestito invece di avere definizioni complete nel tuo albero del codice sorgente offre significativi vantaggi.

Rendere persistenti le identità o i segreti di provisioning necessari in modo che gli sviluppatori non possano accedervi direttamente, costituisce i componenti di base per la governance. Si consideri ad esempio questa illustrazione sulla separazione dei ruoli che è possibile ottenere usando Azure Deployment Environments (ADE).

Qui, i tecnici della piattaforma e altri specialisti sviluppano IaC e altri modelli e li inseriscono in un catalogo. Le operazioni possono quindi aggiungere identità gestite e sottoscrizioni per tipo di ambiente e assegnare sviluppatori e altri utenti autorizzati a usarle per il provisioning.

Gli sviluppatori o la pipeline CI/CD possono quindi usare l'interfaccia della riga di comando di Azure o l'interfaccia della riga di comando per sviluppatori di Azure per effettuare il provisioning dell'infrastruttura preconfigurata e controllata senza avere accesso alla sottoscrizione o alle identità sottostanti necessarie per farlo. Indipendentemente dal fatto che si usi qualcosa come ADE o meno, il sistema di recapito continuo preferito consente di aggiornare l'infrastruttura in modo sicuro e sicuro separando i segreti e il contenuto IaC di origine da posizioni a cui gli sviluppatori non possono accedere o modificare autonomamente.

Abilitare la modalità self-service negli scenari oltre al recapito continuo dell'applicazione

Anche se i concetti di integrazione continua e distribuzione continua sono legati allo sviluppo di applicazioni, molte delle cose che i clienti interni desiderano fornire non sono direttamente associate a una particolare applicazione. Questa può essere un'infrastruttura condivisa, la creazione di un repository, gli strumenti di provisioning e altro ancora.

Per capire dove può essere utile, pensate a dove attualmente avete processi manuali o basati su un service desk. Per ognuno di essi, considerare queste domande:

• Con quale frequenza si verifica questo processo?
• Il processo è lento, soggetto a errori o richiede un lavoro significativo per ottenere?
• Questi processi sono manuali a causa di un passaggio di approvazione obbligatorio o semplicemente della mancanza di automazione?
• I responsabili dell'approvazione hanno familiarità con i sistemi di controllo del codice sorgente e i processi di pull request?
• Quali sono i requisiti di controllo per i processi? Questi differiscono dai requisiti di verifica del vostro sistema di gestione del controllo del codice sorgente?
• Ci sono processi che è possibile iniziare con che sono più bassi rischi prima di passare a quelli più complessi?

Identificare i processi frequenti, ad alta fatica o soggetti a errori come potenziali destinazioni per automatizzare prima di tutto.

Usare tutto come modello di codice

Una delle cose belle su Git oltre alla sua ubiquity è che è progettato per essere una fonte sicura e controllabile di informazioni. Oltre alla cronologia di commit e ai controlli di accesso, i concetti come le richieste pull e la protezione dei rami offrono un modo per stabilire revisori specifici, una cronologia delle conversazioni e controlli automatizzati che devono essere passati prima dell'unione nel ramo principale. In combinazione con motori di attività flessibili come quelli presenti nei sistemi CI/CD, si dispone di un framework di automazione sicuro.

L'idea alla base di tutto il codice è che è possibile trasformare quasi tutto in un file in un repository Git sicuro. Diversi strumenti o agenti connessi al repository possono quindi leggere il contenuto. Il trattamento di tutto come codice facilita la ripetibilità attraverso i modelli e semplifica l'autoservizio per gli sviluppatori. Verranno ora illustrati diversi esempi di come questo può funzionare.

Applicare modelli IaC a qualsiasi infrastruttura

Anche se IaC ha acquisito popolarità per automatizzare il recapito delle applicazioni, il modello si estende a qualsiasi infrastruttura, strumenti o servizi di cui si vuole effettuare il provisioning e la configurazione, non solo quelli associati a un'applicazione specifica. Ad esempio, i cluster Kubernetes condivisi con Flux installato, il provisioning di elementi come DataDog usati da più team e applicazioni o persino la configurazione degli strumenti di collaborazione preferiti.

Il modo in cui questo funziona è avere un repository centralizzato separato e protetto che contiene una serie di file che rappresentano ciò che deve essere provvisto e configurato (in questo caso, qualsiasi cosa dai file Bicep o Terraform ai grafici Helm e ad altri formati nativi di Kubernetes). Un team operativo o un altro gruppo di amministratori è proprietario del repository e gli sviluppatori (o i sistemi) possono inviare pull request (PR). Dopo che questi pull request vengono uniti nel ramo principale da questi amministratori, gli stessi strumenti CI/CD usati durante lo sviluppo delle applicazioni possono entrare in azione per elaborare le modifiche. Si consideri la figura seguente che mostra le identità di distribuzione, IaC e GitHub Actions ospitate negli ambienti di distribuzione di Azure:

Se si usa già un approccio GitOps per la distribuzione di applicazioni, è possibile riutilizzare anche questi strumenti. La combinazione di strumenti come Flux e Operatore di servizio di Azure consente di espandersi all'esterno di Kubernetes:

In entrambi i casi, si dispone di un'origine di informazioni completamente gestita, riproducibile e controllabile, anche se ciò che viene prodotto non è per un'applicazione. Come per lo sviluppo di applicazioni, tutti i segreti o le identità gestite necessarie vengono archiviati nel motore pipeline/flusso di lavoro o nelle funzionalità native di un servizio di provisioning.

Poiché le persone che effettuano richieste pull non hanno accesso diretto a questi segreti, esso fornisce agli sviluppatori un modo per iniziare azioni in modo sicuro che non possono eseguire da soli poiché non hanno l'autorizzazione diretta. In questo modo è possibile rispettare il principio dei privilegi minimi, pur offrendo agli sviluppatori un'opzione self-service.

Tenere traccia dell'infrastruttura provisionata

Quando si inizia a scalare questo approccio, riflettere su come tenere traccia dell'infrastruttura che è stata configurata. Il repository Git è una fonte affidabile per la configurazione, ma non fornisce gli URI specifici e le informazioni sullo stato di ciò che hai creato. Tuttavia, seguendo un approccio basato su tutto come codice si ottiene una fonte di informazioni da sfruttare per sintetizzare un inventario dell'infrastruttura di cui è stato effettuato il provisioning. Il tuo provisioner potrebbe anche essere una buona fonte di queste informazioni su cui puoi fare affidamento. Ad esempio, gli ambienti di distribuzione di Azure includono funzionalità di rilevamento dell'ambiente a cui gli sviluppatori hanno visibilità.

Per saperne di più sul monitoraggio attraverso varie origini dati, vedere Progettare una fondazione self-service per sviluppatori.

Applicare la sicurezza come codice e criteri come modelli di codice

Anche se l'infrastruttura di provisioning è utile, assicurarsi che questi ambienti siano sicuri e in genere seguano i criteri dell'organizzazione è altrettanto importante. Questo ha portato alla diffusione del concetto di politica come codice. In questo caso, i file di configurazione in un repository di controllo del codice sorgente possono essere usati per eseguire operazioni come l'analisi della sicurezza o l'applicazione dei criteri di infrastruttura.

Molti prodotti e progetti open source diversi hanno adottato questo approccio, tra cui Criteri di Azure, Open Policy Agent, GitHub Advanced Security e GitHub CODEOWNERS, tra gli altri. Quando si seleziona l'infrastruttura dell'applicazione, i servizi o gli strumenti, assicurarsi di valutare il livello di supporto di questi modelli. Per altre informazioni sulla ridefinizione dell'applicazione e della governance, vedere Perfezionare la piattaforma dell'applicazione.

Usare tutto come codice per scenari personalizzati

Tutto il codice estende questi modelli a un'ampia gamma di attività di automazione e configurazione oltre IaC. Può supportare non solo la creazione o la configurazione di qualsiasi tipo di infrastruttura, ma anche l'aggiornamento dei dati o l'attivazione di flussi di lavoro in qualsiasi sistema downstream.

La pull request diventa una valida esperienza utente self-service di base per diversi processi, soprattutto quando si è agli inizi. I processi ottengono naturalmente i vantaggi di sicurezza, controllabilità e rollback offerti da Git stesso e i sistemi coinvolti possono anche cambiare nel tempo senza influire sull'esperienza utente.

Team gestiti come codice

Un esempio di applicazione di tutto come codice ai propri scenari è rappresentato dai team come modello di codice. Le organizzazioni applicano questo modello per standardizzare l'appartenenza al team e, in alcuni casi, i diritti di strumenti/servizi per sviluppatori in un'ampia gamma di sistemi. Questo modello elimina i processi manuali di inserimento e rimozione del service desk guidati dalla necessità, per gli sviluppatori e operatori di sistemi, di accedere ai propri concetti di raggruppamento, utente e accesso. I processi manuali di service desk rappresentano un potenziale rischio per la sicurezza perché è possibile sovrapprovisionare l'accesso. Quando si usano i team come modello di codice, la combinazione di git e richieste pull può abilitare self-service da un'origine dati controllabile.

Per un esempio di variante completa e matura di questo modello, vedere il post di blog di GitHub su come gestiscono entitlement. GitHub ha anche reso open source la sofisticata implementazione Entitlements da provare o adottare. Anche se il post di blog descrive complessivamente i diritti dei dipendenti, è possibile applicare il concetto di team-as-code a scenari del team di sviluppo con un ambito più ristretto. Questi team di sviluppo potrebbero non essere rappresentati in un organigramma dei dipendenti e coinvolgono strumenti o servizi proprietari che possono complicare l'onboarding o l'offboarding dei membri del team.

Ecco un riepilogo di una variante semplificata di questa idea che usa un sistema CI/CD e gruppi di provider di identità per coordinare gli aggiornamenti:

In questo esempio:

• Ogni sistema coinvolto è stato configurato per usare il provider di identità (ad esempio, Microsoft Entra ID) per l'accesso Single Sign-On (SSO).
• Si usano gruppi di provider di identità (ad esempio, gruppi entra) tra sistemi per gestire l'appartenenza in base al ruolo per ridurre la complessità e mantenere il controllo centralizzato.

A livello generale, ecco come funziona questo modello:

• Un repository Git centrale e bloccato include un set di file (in genere YAML) che rappresentano ogni team astratto, l'appartenenza dell'utente correlata e i ruoli utente. I proprietari o i responsabili delle approvazioni per le modifiche del team possono anche essere memorizzati nello stesso punto (ad esempio, tramite CODEOWNERS). Il riferimento a un utente in questi file è il provider di identità, ma questo repository funge da fonte di verità per questi team (ma non per gli utenti).
• Tutti gli aggiornamenti a questi file vengono eseguiti tramite richieste pull. Questo collega le conversazioni e i partecipanti associati alla richiesta con il commit Git per la tracciabilità.
• I responsabili e gli utenti individuali possono creare pull request per aggiungere o rimuovere persone, e i responsabili dello sviluppo e altri ruoli possono creare nuovi team usando le pull request con un nuovo file di team da un modello.
• Ogni volta che una richiesta pull viene unita in main, un sistema CI/CD associato al repository aggiorna quindi il sistema del provider di identità e tutti i sistemi downstream in base alle esigenze.

In particolare, il sistema CI/CD:

• Usa l'API di sistema dell'appropriato provider di identità per creare o aggiornare un gruppo di identità del provider per ogni ruolo con esattamente gli individui contenuti nel file (non di più, né di meno).
• Usa le API per ogni sistema downstream per collegare il concetto di raggruppamento dei sistemi a un'identificazione dei gruppi di provider per ogni ruolo, ad esempio GitHub e Azure DevOps. Ciò potrebbe comportare una relazione uno-a-molti tra il team e il sistema a valle per rappresentare un determinato ruolo.
• (Facoltativamente) Usa le API per ogni sistema downstream per implementare la logica delle autorizzazioni associata al meccanismo di raggruppamento del sistema.
• Usa un'API per aggiornare un archivio dati bloccato con i risultati (inclusa l'associazione degli ID del team di sistema downstream) che possono quindi essere utilizzati per uno dei sistemi compilati internamente. È anche possibile archiviare le associazioni per diverse rappresentazioni di sistema degli ID utente per lo stesso utente/account del provider di identità, se necessario.

Se l'organizzazione usa già qualcosa come Entra entitlement management, potrebbe essere possibile omettere la gestione dell'appartenenza ai gruppi da questo modello.

Le esigenze e i criteri possono modificare le specifiche, ma il modello generale può essere adattato a qualsiasi numero di varianti. Tutti i segreti necessari per l'integrazione con qualsiasi sistema downstream vengono mantenuti nel sistema CI/CD (ad esempio, in GitHub Actions o Azure Pipelines) o in un ambiente simile ad Azure Key Vault.

Usare flussi di lavoro con parametri o manualmente attivati esternamente

Alcuni dei problemi correlati al self-service identificati potrebbero non essere favorevoli all'uso dei file in Git. In alternativa, potresti avere un'interfaccia utente da utilizzare per gestire l'esperienza self-service.

Fortunatamente, la maggior parte dei sistemi CI, tra cui GitHub Actions e Azure Pipelines, ha la possibilità di configurare un flusso di lavoro con input che è quindi possibile attivare manualmente tramite le interfacce utente o le interfacce della riga di comando. Dato che gli sviluppatori e i ruoli operativi correlati hanno probabilmente già familiarità con queste esperienze degli utenti, i trigger manuali possono aumentare il modello 'everything as code' per abilitare l'automazione per le attività (o i processi) che non hanno una rappresentazione di file naturale o devono essere completamente automatizzati senza richiedere un processo di pull request.

Il sistema CI potrebbe consentire di acconsentire esplicitamente all'attivazione di questi flussi di lavoro o pipeline dalle proprie esperienze utente tramite un'API. Per GitHub Actions, la chiave per eseguire questa operazione è l'API REST Actions per attivare un evento dispatch del flusso di lavoro per attivare un'esecuzione 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. Indipendentemente dal fatto che venga attivato manualmente o tramite un'API, ogni flusso di lavoro può supportare un set di input aggiungendo una configurazione workflow_dispatch al file YAML del flusso di lavoro. Ad esempio, questo è il modo in cui i toolkit del portale come Backstage.io interagiscono con GitHub Actions.

Il flusso di lavoro o il sistema di processi del sistema CI/CD tiene senza dubbio traccia delle attività, segnala lo stato e include log dettagliati che gli sviluppatori e i team operativi possono usare per vedere cosa è andato storto. Questo approccio presenta alcuni degli stessi vantaggi in termini di sicurezza, verificabilità e visibilità del modello tutto come codice. Tuttavia, una cosa da tenere presente è che qualsiasi azione eseguita da questi flussi di lavoro o pipeline è simile a un'identità di sistema (ad esempio, un'entità servizio o un'identità gestita in Microsoft Entra ID) ai sistemi downstream.

Si avrà visibilità sugli utenti che avviano le richieste nel sistema CI/CD, ma è necessario valutare se si tratta di informazioni sufficienti e assicurarsi che le impostazioni di conservazione CI/CD siano conformi ai requisiti di controllo per i casi in cui queste informazioni sono critiche.

In altri casi, gli strumenti integrati con potrebbero avere i propri meccanismi di rilevamento su cui è possibile fare affidamento. Ad esempio, questi strumenti CI/CD hanno quasi sempre diversi meccanismi di notifica disponibili, come l'uso di un canale Microsoft Teams o Slack , che consente di mantenere chiunque invii una richiesta per ottenere gli aggiornamenti dello stato e il canale fornisce un record informale di ciò che è successo. Questi stessi motori di flussi di lavoro sono spesso già progettati per l'integrazione con gli strumenti operativi per estendere ulteriormente l'utilità di questi modelli.

In sintesi, è possibile implementare un'automazione usando i file archiviati in un repository di controllo del codice sorgente grazie alla flessibilità degli strumenti CI/CD e alle esperienze utente predefinite. Per scoprire in che modo le piattaforme di sviluppo interne possono usare questo approccio come punto di partenza senza compromettere le funzionalità più sofisticate nel tempo, vedere Progettare una base self-service per sviluppatori.

Automatizzare la configurazione degli ambienti di codifica per sviluppatori

Un altro problema comune nei sistemi di progettazione è il bootstrap e la normalizzazione dell'ambiente di codifica per sviluppatori. Ecco alcuni dei problemi comuni che potresti conoscere in questa area:

• In alcuni casi, possono essere necessarie settimane prima che uno sviluppatore possa effettuare la sua prima pull request. Si tratta di un'area problematica quando si trasferiscono gli sviluppatori tra equipaggi di funzionalità e progetti abbastanza frequentemente (ad esempio, in organizzazioni a matrice), è necessario aumentare le prestazioni dei terzisti o si trovano in un team che si trova in una fase di assunzione.
• L'incoerenza tra gli sviluppatori e con i sistemi CI può portare a frequenti problemi di "funziona sul mio computer" anche per i membri esperti del team.
• La sperimentazione e l'aggiornamento di framework, tempi di esecuzione e altri software possono anche interrompere gli ambienti di sviluppo esistenti e causare perdita di tempo cercando di capire esattamente cosa è andato storto.
• Per i lead di sviluppo, le revisioni del codice possono rallentare lo sviluppo, in quanto potrebbero richiedere una modifica alla configurazione per testare e annullarle al termine della revisione.
• Inoltre, i membri e gli operatori del team devono dedicare tempo ad aumentare i ruoli correlati oltre allo sviluppo (operatori, QA, business, sponsor) per aiutare a testare, vedere i progressi, formare i ruoli aziendali e promuovere il lavoro svolto dal team.

Parte dei percorsi pavimentati

Per risolvere questi problemi, considerare la configurazione di strumenti e utilità specifici come parte dei percorsi ben definiti. La configurazione del computer per sviluppatori di script può essere utile ed è possibile riutilizzare questi stessi script nell'ambiente CI. Tuttavia, prendere in considerazione il supporto di ambienti di sviluppo in contenitori o virtualizzati a causa dei vantaggi che possono offrire. Questi ambienti di codifica possono essere configurati in anticipo in base alle specifiche dell'organizzazione o del progetto.

Sostituzione della workstation e compatibilità con Windows

Se si ha come destinazione Windows o si vuole eseguire la virtualizzazione completa delle workstation (strumenti client e impostazioni del sistema operativo host oltre alle impostazioni specifiche del progetto), le macchine virtuali offrono in genere le funzionalità migliori. Questi ambienti possono essere utili per qualsiasi elemento, dallo sviluppo di client Windows fino al servizio Windows o alla gestione e manutenzione di applicazioni Web .NET Framework completo.

Avvicinarsi	Esempi
Usare macchine virtuali ospitate nel cloud	Microsoft Dev Box è un'opzione completa di virtualizzazione della workstation Windows con integrazione predefinita per il software di gestione desktop.
Usare macchine virtuali locali	Hashicorp Vagrant è un'ottima opzione ed è possibile usare HashiCorp Packer per compilare immagini di macchine virtuali sia per it che per Dev Box.

Virtualizzazione dell'area di lavoro e destinazione di Linux

Se si usa Linux come destinazione, prendere in considerazione un'opzione di virtualizzazione dell'area di lavoro. Queste opzioni si concentrano meno sulla sostituzione del desktop per sviluppatori e altro ancora sulle aree di lavoro specifiche del progetto o dell'applicazione.

Avvicinarsi	Esempi
Usare contenitori ospitati nel cloud	GitHub Codespaces è un ambiente basato sul cloud per i contenitori di sviluppo che supporta l'integrazione con VS Code, IntelliJ di JetBrains e strumenti basati su terminale. Se questo o un servizio simile non soddisfa le proprie esigenze, è possibile usare il supporto ssh o tunnel remoti di VS Code con i contenitori di sviluppo in macchine virtuali Linux remote. Opzione basata su tunnel che funziona non solo con il client, ma con il vscode.dev basato sul Web.
Usare i contenitori locali	Se si preferisce invece un'opzione di contenitori di sviluppo locale o oltre a quella ospitata nel cloud, i contenitori di sviluppo hanno un solido supporto in VS Code, il supporto in IntelliJ e altri strumenti e servizi.
Usare macchine virtuali ospitate nel cloud	Se si trovano contenitori troppo limitati, il supporto SSH in strumenti come VS Code o JetBrains come IntelliJ consente di connettersi direttamente alle macchine virtuali Linux gestite dall'utente. Visual Studio Code ha anch'essa un'opzione basata su tunnel.
Usare il sottosistema Windows per Linux	Se i tuoi sviluppatori utilizzano esclusivamente Windows, Windows Subsystem for Linux (WSL) è un ottimo modo per gli sviluppatori per utilizzare Linux localmente. È possibile esportare una distribuzione WSL per il team e condividerla con tutti gli elementi configurati. Per un'opzione cloud, i servizi di workstation cloud come Microsoft Dev Box possono anche sfruttare WSL per lo sviluppo Linux.

Creare modelli di avvio applicazione che includano una configurazione corretta.

Il grande vantaggio del modello "everything as code" è che può mantenere gli sviluppatori sui percorsi definiti che hai stabilito fin dall'inizio. Se si tratta di una sfida per l'organizzazione, i modelli di applicazione possono diventare rapidamente un modo fondamentale per riutilizzare i blocchi predefiniti per favorire la coerenza, promuovere la standardizzazione e codificare le procedure consigliate dell'organizzazione.

Per iniziare, è possibile usare qualcosa di semplice come un repository di modelli GitHub, ma se l'organizzazione segue un modello monorepo questo potrebbe essere meno efficace. È anche possibile creare modelli che consentono di configurare un elemento che non è direttamente correlato a un albero di origine dell'applicazione. È invece possibile usare un motore di creazione modelli come cookiecutter, Yeoman o un'interfaccia della riga di comando per sviluppatori di Azure (azd) che, oltre alla creazione di modelli e alla configurazione CI/CD semplificata, offre anche un pratico set di comandi per sviluppatori. Poiché l'interfaccia della riga di comando per sviluppatori di Azure può essere usata per gestire la configurazione dell'ambiente in tutti gli scenari, si integra con gli ambienti di distribuzione di Azure per garantire una maggiore sicurezza, un IaC integrato, il rilevamento dell'ambiente, la separazione delle problematiche e la configurazione semplificata dei CD.

Dopo aver creato un set di modelli, i responsabili dello sviluppo possono usare questi strumenti da riga di comando o altre esperienze utente integrate per fare lo scaffolding del contenuto per le loro applicazioni. Tuttavia, poiché gli sviluppatori potrebbero non avere l'autorizzazione per creare repository o altri contenuti dai modelli, è anche un'altra opportunità per usare flussi di lavoro attivati manualmente, flussi di lavoro con parametri o pipeline. È possibile configurare gli input in modo che il sistema CI/CD crei qualsiasi elemento da un repository all'infrastruttura per loro conto.

Rimanere corretti e ottenere il corretto

Tuttavia, per facilitare la scalabilità, questi modelli di applicazione devono fare riferimento a blocchi predefiniti centralizzati laddove possibile (ad esempio, modelli IaC o anche flussi di lavoro e pipeline CI/CD). In effetti, trattando questi blocchi predefiniti centralizzati come una propria forma di modelli di partenza corretti potrebbe essere una strategia efficace per risolvere alcuni dei problemi identificati.

Ognuno di questi singoli modelli può essere applicato non solo alle nuove applicazioni, ma anche a quelle esistenti che si intende aggiornare come parte di una campagna di recupero per implementare linee guida aggiornate o migliorate. Anche meglio, questa centralizzazione consente di mantenere le applicazioni nuove e esistenti rimanere corrette, consentendo di evolvere o espandere le procedure consigliate nel tempo.

Contenuto del modello

Quando si creano modelli, è consigliabile prendere in considerazione le aree seguenti.

Area	Dettagli
Codice sorgente di esempio sufficiente per guidare modelli di app, SDK e uso di strumenti	Includere codice e configurazione per indirizzare gli sviluppatori verso linguaggi consigliati, modelli di app e servizi, API, SDK e modelli architetturali. Assicurarsi di includere il codice per la traccia distribuita, la registrazione e l'osservabilità usando gli strumenti scelti.
Script di compilazione e distribuzione	Fornire agli sviluppatori un modo comune per attivare una compilazione e una distribuzione locale/sandbox. Includere la configurazione di debug nell'IDE o nell'editor per gli strumenti scelti per usarli. Questo è un modo importante per evitare problemi di manutenzione e impedire che CI/CD sia fuori sincronizzazione. Se il motore di templating è opinionato come l'interfaccia della riga di comando per sviluppatori di Azure, potrebbero già esserci dei comandi che puoi usare.
Configurazione per CI/CD	Fornire flussi di lavoro/pipeline per la compilazione e la distribuzione di applicazioni in base alle raccomandazioni. Sfruttare i vantaggi di flussi di lavoro/pipeline centralizzati, riutilizzabili o basati su modelli per mantenerli up-to-date. Infatti, questi flussi di lavoro o pipeline riutilizzabili possono diventare modelli di template autonomi. Assicurarsi di prendere in considerazione un'opzione per attivare manualmente questi flussi di lavoro.
Infrastruttura come asset di codice	Fornire configurazioni IaC consigliate, inclusi i riferimenti a moduli gestiti centralmente o elementi del catalogo, per garantire che l'infrastruttura sia configurata secondo le migliori pratiche sin dall'inizio. Questi riferimenti possono anche aiutare i team a continuare a operare correttamente col passare del tempo. In combinazione con flussi di lavoro e pipeline, è anche possibile includere IaC o EaC per fornire praticamente qualsiasi cosa.
Sicurezza e politiche come risorse di codice	Il movimento DevSecOps ha portato la configurazione di sicurezza nel codice, migliorando l'efficacia per i modelli. Alcune politiche come artefatti di codice possono essere applicate anche a livello di applicazione. Includere tutto, dai file come CODEOWNERS alla configurazione di scansione come dependabot.yaml in GitHub Advanced Security. Fornire flussi di lavoro pianificati/esecuzioni di pipeline per le analisi usando qualcosa come Defender for Cloud insieme alle esecuzioni di test dell'ambiente. Questo aspetto è importante per la sicurezza della supply chain e assicurarsi di tenere conto delle immagini dei contenitori oltre ai pacchetti e al codice dell'applicazione. Questi passaggi aiutano i team di sviluppo a rimanere sulla giusta strada.
Osservabilità, monitoraggio e registrazione	Parte dell'abilitazione del self-service è fornire una facile visibilità nelle applicazioni una volta distribuite. Oltre all'infrastruttura di runtime, assicurarsi di includere la configurazione per l'osservabilità e il monitoraggio. Nella maggior parte dei casi, esiste un aspetto IaC da configurare (ad esempio, distribuzione dell'agente, strumentazione) mentre in altri potrebbe essere un altro tipo di artefatto di codice config-as (ad esempio, il monitoraggio dei dashboard per Azure Application Insights). Infine, assicurarsi di includere codice di esempio per la traccia distribuita, la registrazione e l'osservabilità usando gli strumenti scelti.
Configurazione dell'ambiente di codifica	Includere i file di configurazione per linter di codice, formattatori, editor e IDE. Includere script di installazione insieme ai file di virtualizzazione per l'area di lavoro o la workstation come devcontainer.json, devbox.yaml, Dockerfile per sviluppatori, file Docker Compose o Vagrantfiles.
Configurazione di test	Fornire file di configurazione per test unitari e test più approfonditi usando i servizi preferiti, ad esempio Microsoft Playwright Testing per l'interfaccia utente o il test delle app di Azure.
Configurazione dello strumento di collaborazione	Se il sistema di gestione dei problemi e il sistema di gestione del controllo del codice sorgente supportano anche i modelli task/issue/PR, includerli anche. Nei casi in cui è necessaria un'installazione maggiore, è possibile specificare facoltativamente un flusso di lavoro o una pipeline che aggiorna i sistemi usando un'interfaccia della riga di comando o un'API disponibile. Ciò consente anche di configurare altri strumenti di collaborazione, ad esempio Microsoft Teams o Slack.

Contenuti correlati

• Centro risorse DevOps di Microsoft
• Contenitori Quadro di Sicurezza della Catena di Fornitura
• Architettura di base CI/CD con Azure Pipelines
• Perfezionare la piattaforma dell'applicazione