Applicare sistemi di ingegneria del software

Il miglioramento self-service degli sviluppatori deve essere uno dei primi problemi affrontati nel percorso di progettazione 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 progettazione per affrontare una gamma più ampia di scenari self-service e informazioni dettagliate su come incapsulare le procedure consigliate nei modelli che consentono di iniziare a destra e rimanere corretti.

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. È progettato per migliorare la collaborazione tra ruoli storicamente silo come sviluppo, operazioni IT, progettazione della qualità e sicurezza. Si stabilisce un ciclo continuo tra sviluppo, distribuzione, monitoraggio, osservazione e feedback. DevSecOps esegue i livelli in questo ciclo con procedure di sicurezza continue in tutto il processo di sviluppo di 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, ma si prevede di gestire, gestire e pagare separatamente i propri strumenti pur rispettando 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. In quanto responsabile dell'ingegneria della piattaforma, lo ha messo:

Puoi ancora fare la tua cosa, ma farlo in una direzione che stiamo andando... è possibile cambiare quello che vuoi, ma questo diventa la tua responsabilità. Si possiedono i cambiamenti – si possiedono i coltelli taglienti. - Mark, responsabile dell'ingegneria della piattaforma, grande azienda multinazionale europea di vendita 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, i team di sviluppo di lavoro aggiuntivi assumono naturalmente causeranno la loro necessità di passare a un percorso supportato nel tempo.

Se si preferisce una strategia di consolidamento, la migrazione di applicazioni esistenti potrebbe essere più lavoro del previsto, quindi è probabile che si voglia iniziare a concentrarsi sull'aspetto giusto di questo spazio e concentrarsi sui nuovi progetti. Questo ti dà il primo sentiero pavimentato, mentre tutto ciò che esiste è intrinsecamente non pavimentato. I team di sviluppo nel percorso non pavimentato prenderanno quindi in considerazione lo spostamento dopo che il nuovo percorso pavimentato ne mostra il valore all'organizzazione. A questo punto è possibile eseguire una campagna di recupero per ottenere tutti gli utenti sullo stato desiderato tramite una comunicazione bidirezionale, poiché i team di sviluppo lo considerano come 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 nell'evidenziare ciò che i team escono da loro piuttosto che attraverso l'adozione forzata. Poiché la piattaforma per sviluppatori interna è incentrata su come rendere questi stessi team felici, budget e pressione tempo-to-value sui singoli leader si occupa del resto. Ottieni campagne giuste, quindi fornisci un modo per conversazioni bidirezionali sul modo migliore per chi si sposta su un percorso non pavimentato per passare.

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 il recapito continuo

Se non è già stato implementato, è probabile che i problemi identificati durante la pianificazione puntino a problemi che l'integrazione continua (CI) e il recapito continuo (CD) possono contribuire alla risoluzione. 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 è già stato implementato un modo per distribuire continuamente l'applicazione nell'infrastruttura esistente, è consigliabile usare l'infrastruttura come codice (IaC) per creare o aggiornare l'infrastruttura dell'applicazione necessaria come parte della pipeline cd.

Si considerino ad esempio queste illustrazioni che mostrano due approcci che usano GitHub Actions per aggiornare l'infrastruttura e distribuirla in servizio Azure Kubernetes: una usando 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 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 tra applicazioni, è necessario pubblicare centralmente 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 (ACR), DockerHub o il catalogo in Ambienti di distribuzione di Azure (ADE). 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 come le risorse di supporto crossplane in più cloud. In questo modo è possibile usare grafici Helm centralizzati o comuni in un formato simile a Registro Azure Container 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, app contenitore di Azure (ACA) e il recente progetto di incubazione RADIUS OSS sperimentale sono più opinioni rispetto all'uso diretto di Kubernetes, ma semplificano anche l'esperienza di sviluppo. Il modulo di training Descrivere i tipi di servizio cloud consente di comprendere i vantaggi e i svantaggi di modelli diversi. Indipendentemente dal fatto che il riferimento a IaC centralizzato e gestito anziché avere definizioni complete nell'albero di origine presenta vantaggi significativi.

Rendere persistenti le identità o i segreti di provisioning necessari in modo che gli sviluppatori non possano accedervi direttamente nei blocchi predefiniti 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 relativi all'integrazione continua e alla distribuzione continua sono legati allo sviluppo di applicazioni, molte delle cose che i clienti interni vogliono effettuare il provisioning non associano direttamente a una determinata 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, considerare la posizione in cui sono attualmente presenti processi basati su service desk o manuali. 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 approvazione hanno familiarità con i sistemi di controllo del codice sorgente e i processi di richiesta pull?
• Quali sono i requisiti di controllo per i processi? Queste differenze sono diverse dai requisiti di controllo del sistema di 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, elevati o soggetti a errori come potenziali destinazioni per automatizzare per primi.

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 il codice facilita la ripetibilità tramite modelli e semplifica la funzionalità self-service 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 facilitare l'automazione del recapito delle applicazioni, il modello si estende a qualsiasi infrastruttura, strumenti o servizi di cui si vuole eseguire il provisioning e la configurazione, non solo quelli associati a un'applicazione specifica. Ad esempio, K8 condivisi con cluster con Flux installato, provisioning di elementi come DataDog usati da più team e applicazioni o persino configurare gli strumenti di collaborazione preferiti.

Il modo in cui funziona è che si dispone di un repository centralizzato separato e protetto che ospita una serie di file che rappresentano ciò che deve essere effettuato il provisioning e la configurazione (in questo caso qualsiasi elemento da Bicep, Terraform, ai grafici Helm e ad altri formati nativi Kubernetes). Un team operativo o un altro set di amministratori è proprietario del repository e gli sviluppatori (o sistemi) possono inviare richieste pull. Dopo che queste richieste pull vengono unite nel ramo principale da questi amministratori, gli stessi strumenti CI/CD usati durante lo sviluppo di applicazioni possono avviare per elaborare le modifiche. Si consideri questa illustrazione che usa GitHub Actions e le identità di distribuzione e IaC 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 avranno accesso diretto a questi segreti, offre agli sviluppatori un modo per avviare in modo sicuro azioni che non hanno l'autorizzazione diretta per eseguire se stessi. In questo modo è possibile rispettare il principio dei privilegi minimi, pur offrendo agli sviluppatori un'opzione self-service.

Tenere traccia dell'infrastruttura di cui è stato effettuato il provisioning

Quando si inizia a ridimensionare questo approccio, considerare come tenere traccia dell'infrastruttura di cui è stato effettuato il provisioning. Il repository Git è un'origine di verità per la configurazione, ma non indica gli URI e le informazioni sullo stato specifiche su ciò che è stato 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 provisioner potrebbe anche essere una buona fonte di queste informazioni che è possibile sfruttare. Ad esempio, gli ambienti di distribuzione di Azure includono funzionalità di rilevamento dell'ambiente a cui gli sviluppatori hanno visibilità.

Per altre informazioni sul rilevamento in varie origini dati, vedere Progettare una base 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 all'aumento del concetto di "criteri 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 richiesta pull diventa un'esperienza utente self-service di base ottimale per diversi processi, in particolare quando si inizia. 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.

Teams 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 di onboarding e offboarding manuali del service desk basati sulla necessità di 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 effettuare il overprovisioning dell'accesso. Quando si usano i team come modello di codice, la combinazione di richieste git e 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 open source la loro sofisticata implementazione entitlement per provare o adottare. Anche se il post di blog descrive i diritti dei dipendenti all-up, è possibile applicare i team come concetto di codice agli scenari del team di sviluppo con 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 useranno 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 approvazione per le modifiche del team possono anche essere archiviati 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 correlati alla richiesta di commit git per la verificabilità.
• I lead e i singoli utenti possono creare richieste pull per aggiungere/rimuovere persone e i lead di sviluppo e altri ruoli possono creare nuovi team usando le richieste pull che con un nuovo file del 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 del provider di identità appropriata per creare o aggiornare un gruppo di provider di identità per ogni ruolo con esattamente gli individui nel file (non più, non 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 downstream per rappresentare un 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,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, potrebbe essere disponibile un'interfaccia utente che si vuole usare per guidare 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 utente, i trigger manuali possono aumentare tutto come modello di codice 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 richiesta pull.

Il sistema CI può 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 interagire 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. In questo modo, presenta alcuni degli stessi vantaggi di sicurezza, controllabilità e visibilità di tutti gli elementi come modello di 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 questo settore:

• In alcuni casi, possono essere necessarie settimane prima che uno sviluppatore possa accedere alla prima richiesta pull. 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ò causare frequenti problemi di "funzionamento sul computer" anche per i membri del team con esperienza.
• 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 destinazione di 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 client Windows al servizio Windows o dalla gestione e la gestione di applicazioni Web .NET full framework.

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.

Creare modelli di applicazione iniziali che includono mantenere la configurazione corretta

La cosa importante di tutto come modello di codice è che può mantenere gli sviluppatori sui percorsi pavimentati 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 lead di sviluppo possono usare questi strumenti da riga di comando o altre esperienze utente integrate per eseguire lo scaffolding del contenuto per le 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/pipeline attivati manualmente. È possibile configurare gli input in modo che il sistema CI/CD crei qualsiasi elemento da un repository all'infrastruttura per loro conto.

Rimanere a destra e ottenere il giusto

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

Contenuto correlato

• Centro risorse DevOps di Microsoft
• Sicurezza della supply chain dei contenitori
• CI/CD per le app del servizio Azure Kubernetes con GitHub Actions e Gitflow