Condividi tramite

Suggerimenti per la standardizzazione di strumenti e processi

  • Articolo

Si applica a questa raccomandazione per l'eccellenza operativa di Azure Well-Architected Framework:

OE:04 Ottimizzare i processi di sviluppo e controllo della qualità del software seguendo le procedure comprovate del settore per lo sviluppo e i test. Per la designazione di ruolo non ambigua, standardizzare le procedure tra componenti come strumenti, controllo del codice sorgente, modelli di progettazione dell'applicazione, documentazione e guide di stile.

Guida correlata: Migliorare la velocità di compilazione | Usare l'integrazione continua

Questa guida descrive le raccomandazioni per definire gli standard per gli strumenti e i processi di sviluppo software. La definizione di procedure coerenti comporta un team efficiente del carico di lavoro e un lavoro di alta qualità. I team con prestazioni elevate usano strumenti e processi collaudati del settore per ridurre al minimo lo sforzo sprecato e potenziali errori di codice.

Strategie di progettazione chiave

Il primo passaggio dell'ottimizzazione delle procedure di sviluppo è la standardizzazione di strumenti e processi. Quando possibile, usare soluzioni comprovate del settore anziché sviluppare soluzioni interne. Per ottimizzare ulteriormente le procedure, adottare strumenti con poco codice e senza codice. Questi strumenti consentono di concentrare le attività sull'applicazione e di risparmiare tempo. Per tutti gli strumenti e i processi standardizzati, implementare il training in modo che i team comprendano e li usino in modo efficiente. Per definire gli standard che consentono di ottimizzare le procedure di sviluppo, prendere in considerazione le raccomandazioni seguenti.

Usare strumenti ben noti e maturi off-the-shelf

Usa strumenti ben noti e maturi fuori uso e standardizza il loro uso. I team di progettazione altamente efficaci adottano i migliori strumenti di classe. Questo approccio riduce al minimo la necessità di sviluppare soluzioni per la pianificazione, lo sviluppo, il test, la collaborazione e l'integrazione continua e il recapito continuo (CI/CD). Molte aziende offrono agli sviluppatori una scelta tra alcuni strumenti, ma tutte le opzioni sono strumenti standard per l'organizzazione e vengono convalidate internamente. Soprattutto, scegliere gli strumenti che soddisfano i requisiti per il carico di lavoro. Gli strumenti off-the-shelf devono fornire le funzioni seguenti:

  • Pianificazione del lavoro e gestione del backlog

  • Controllo della versione e repository

  • Pipeline CI/CD

  • Test, ad esempio integrazione, fumo, utente sintetico, simulazione, caos e altri test di qualità

  • Sviluppo di codice

In alcuni casi, uno strumento o una suite di strumenti potrebbe fornire diverse funzioni. Assicurarsi di comprendere le funzionalità degli strumenti e le relative limitazioni in modo che soddisfino i requisiti tra le funzioni.

Determinare se è necessario investire in strumenti costosi o versioni Premium di strumenti. Prendere in considerazione il tempo e lo sforzo di sviluppare soluzioni personalizzate rispetto alle funzionalità offerte dagli strumenti Premium. Considerare i costi monouso rispetto ai costi ricorrenti. Nella maggior parte dei casi, gli strumenti off-the-shelf offrono un valore più elevato al team.

Usare strumenti di intelligenza artificiale, senza codice e poco codice quando sono pratici. Gli strumenti con poco codice e senza codice consentono agli sviluppatori esperti di risparmiare tempo consentendo loro di collegare facilmente funzionalità anziché eseguire l'intero processo di sviluppo del codice. Questi strumenti consentono anche ai membri del team del carico di lavoro che potrebbero non essere sottoposti a training per contribuire al funzionamento del carico di lavoro. Gli strumenti di intelligenza artificiale possono essere utili per lo sviluppo, le revisioni e l'ottimizzazione del codice.

Standardizzare la strategia di diramazione

Scegliere un modello basato su trunk quando possibile. La ramificazione basata su trunk mantiene sincronizzato il team di sviluppo del carico di lavoro e incoraggia il recapito continuo. Definire i criteri dei rami per proteggere rami importanti, ad esempio il ramo principale. Per altre informazioni, vedere Adottare una strategia di diramazione Git e i criteri e le impostazioni dei rami.

Valutare le metriche per quantificare l'efficacia dello sviluppo

I team di sviluppo software e controllo qualità possono migliorare solo se possono quantificare la loro efficacia. Per quantificare l'efficacia, è necessario identificare le metriche che misurano la velocità dello sviluppatore e definiscono gli indicatori KPI. Esempi di queste metriche includono:

  • Frequenza di distribuzione: numero di distribuzioni distribuite ogni giorno da ogni sviluppatore.

  • Lead time: tempo necessario per un'attività o una storia utente per passare dal backlog a una distribuzione di produzione.

  • Tempo medio di risoluzione: tempo medio impiegato per la correzione di bug o difetti nel codice.

  • Frequenza degli errori di modifica: percentuale di modifiche che causano un errore.

Per aiutare gli stakeholder e il team del carico di lavoro a tenere traccia facilmente della velocità, visualizzare gli indicatori KPI usando dashboard o altri strumenti di creazione di report.

Standardizzare il modo in cui il team del carico di lavoro scrive, esamina e documenta il codice

Standardizzare il modo in cui il team del carico di lavoro scrive, esamina e documenta il codice usando una guida di stile. Uno stile standard semplifica la collaborazione e facilita l'onboarding di nuovi sviluppatori. Per lavorare in modo efficace, i nuovi sviluppatori devono conoscere il funzionamento del team che si occupa del carico di lavoro. Una guida con standard chiaramente definiti può facilitare il processo di training. Nella guida di stile definire gli standard per linguaggi di sviluppo, librerie, framework e altre convenzioni.

Quando è pratico, usare gli strumenti per applicare gli standard di formattazione del codice. Ad esempio, Visual Studio offre diversi strumenti che analizzano il codice per lo stile, la qualità, la gestibilità, la progettazione e altri problemi. Per l'infrastruttura come codice (IaC), è possibile usare Checkov o Terrascan per Terraform.

Per garantire la coerenza ed evitare potenziali confusioni, la guida di stile deve includere convenzioni di denominazione standard per artefatti, ambienti, rami, compilazioni ed esecuzioni.

È anche consigliabile impostare linee guida e standard per il grado di varianza consentito negli ambienti. Se sono presenti nuovi linguaggi, framework o altre tecnologie che i membri del team del carico di lavoro vogliono aggiungere all'elenco standard, implementare un processo per l'uso di tali strumenti in un ambiente sandbox o inferiore. Testare la redditività e sostituire le tecnologie esistenti, se appropriato.

Usare i record delle decisioni relative all'architettura (ADR) per mantenere un record cronologico delle decisioni di progettazione del team del carico di lavoro. Le adR consentono ai team di mantenere una conoscenza aggiornata del carico di lavoro. Aiutano anche i nuovi membri del team a conoscere le decisioni di progettazione prese durante il ciclo di vita del carico di lavoro. Assicurarsi che le adr siano controllate dalla versione.

Nell'ADR includere:

  • Strumenti e tecnologie specifici, ad esempio usando SQL o NoSQL, scelti dal team.

  • I motivi per le decisioni del team.

  • Altre opzioni considerate, che consentono di contestualizzare la decisione finale.

  • Requisiti funzionali e non funzionali che vengono inseriti in decisioni.

  • Contesto del processo decisionale, come il problema risolto.

Implementare gli standard per affrontare il debito tecnico

Adottare una mentalità per la quale il debito tecnico è intenzionale e necessario per i risultati finali del team che si occupa del carico di lavoro. Questa mentalità motiva il team a prendere in considerazione e affrontare con regolarità il debito tecnico al fine di evitarne l'accumulo. Risolvere il debito tecnico come attività ricorrente regolarmente nel backlog.

Si supponga, ad esempio, che il team abbia standardizzato in una libreria. Nel corso del tempo, è necessario passare a una libreria diversa per le nuove funzionalità nel carico di lavoro. Tale transizione potrebbe comportare un debito tecnico. Spesso, le transizioni di questo tipo possono lasciare il team del carico di lavoro che supporta due tecnologie perché non possono passare completamente senza problemi. Il team del carico di lavoro deve assegnare priorità al completamento della transizione perché quando il carico di lavoro raggiunge le nuove funzionalità, gli stakeholder sono soddisfatti e hanno meno probabilità di considerare il debito tecnico.

Standardizzare la modalità di applicazione del controllo delle versioni agli artefatti

Standardizzare la modalità di applicazione del controllo delle versioni agli artefatti e il modo in cui il controllo delle versioni viene esposto internamente ed esternamente. Ad esempio, i sistemi con connessione client devono esporre la versione in esecuzione nell'interfaccia utente. Questa tecnica è utile quando il team del carico di lavoro risolve i problemi perché il cliente può comunicare facilmente la versione usata. Le interfacce REST possono esporre versioni per determinati componenti o database. È possibile usare una tabella specifica nei metadati per uno schema per esporre la versione dello schema.

Usare modelli di progettazione di applicazioni comprovati del settore per garantire che l'applicazione sia affidabile, efficiente e sicura. Usare questi modelli per risparmiare tempo e impegno rispetto allo sviluppo di soluzioni personalizzate per l'applicazione. Scegliere i modelli che traggono vantaggio dal carico di lavoro. Esaminare regolarmente i modelli di progettazione per assicurarsi di usare i modelli corretti man mano che il carico di lavoro si evolve.

Implementare un approccio di spostamento a sinistra per il test

Implementare un approccio di spostamento a sinistra per testare eseguendo unit test in anticipo e spesso durante il processo di sviluppo. I test frequenti in ogni ambiente di sviluppo consentono agli sviluppatori di acquisire fiducia nelle applicazioni. Per creare la strategia di test con un approccio di spostamento a sinistra, considerare i principi seguenti:

  • Scrivere test al livello più basso possibile. Favorire i test con le dipendenze esterne più poche ed eseguire test come parte della compilazione.

  • Scrivere test una sola volta ed eseguire test ovunque, inclusa la produzione. Scrivere test che è possibile eseguire in ogni ambiente di sviluppo senza tenere conto di fattori specifici di un ambiente, ad esempio segreti crittografati o configurazioni.

  • Progettare il carico di lavoro per i test. Quando si sviluppa l'applicazione, rendere testability un requisito.

  • Considerare il codice di test come codice dell'applicazione. Applicare gli stessi standard di qualità e sviluppo al codice dell'applicazione e al codice di test. Archiviare il codice di test insieme al codice dell'applicazione. Sviluppare e gestire il codice di test con il codice dell'applicazione. Per garantire la qualità dei test, eliminare i test che non sono affidabili.

  • Prendere in considerazione la proprietà del test, basata sulla proprietà del carico di lavoro. Il team del carico di lavoro è proprietario dei test e non deve basarsi su altri team per testare il codice.

  • Automatizzare i test il più possibile. Il codice automatizzato consente di ridurre il carico di lavoro del team del carico di lavoro e di applicare una qualità coerente.

Per indicazioni dettagliate sull'implementazione di una strategia di test DevOps, vedere Shift testing left with unit test (Shift testing left with unit test).

Richiedere le procedure DevSecOps come parte delle procedure operative standard. Il team del carico di lavoro deve comprendere le procedure di sicurezza correlate allo sviluppo software e alla garanzia della qualità. Devono seguire queste procedure senza eccezioni. Per altre informazioni, vedere Guida al ciclo di vita dello sviluppo della sicurezza.

Implementare gli standard per la denominazione e l'assegnazione di tag alle risorse

L'implementazione di convenzioni di assegnazione di tag e denominazione è una procedura consigliata per la gestione e l'organizzazione delle risorse di Azure. L'assegnazione di tag e le convenzioni di denominazione consentono di identificare, classificare e raggruppare le risorse in base a attributi comuni, ad esempio ambiente, applicazione, proprietario o centro di costo. Consentono anche la sicurezza, l'automazione, la creazione di report e la governance delle risorse tra sottoscrizioni e gruppi di risorse.

Alcuni dei vantaggi dell'uso di tag e convenzioni di denominazione standardizzate sono:

  • Offrono coerenza e chiarezza per l'identificazione e la gestione delle risorse, semplificando l'individuazione e la ricerca tra le API portale di Azure, PowerShell, l'interfaccia della riga di comando e le API.
  • Consentono di filtrare e raggruppare le risorse per scopi di fatturazione, monitoraggio, sicurezza e conformità.
  • Supportano la gestione del ciclo di vita delle risorse, ad esempio il provisioning, la rimozione delle autorizzazioni, il backup e il ripristino.
  • Sono essenziali per scopi di sicurezza. Se si verifica un evento imprevisto di sicurezza, è fondamentale identificare rapidamente i sistemi interessati, le funzioni supportate da tali sistemi e il potenziale impatto aziendale.

Per altre informazioni sull'uso delle convenzioni di denominazione per le risorse cloud, vedere Definire la convenzione di denominazione. Per altre informazioni su come applicare tag di metadati alle risorse cloud, vedere Definire la strategia di assegnazione di tag.

Facilitazione di Azure

  • Azure DevOps è una raccolta di servizi che è possibile usare per creare una pratica di sviluppo collaborativa, efficiente e coerente. Azure DevOps aggrega le soluzioni seguenti:

    • Azure Pipelines offre servizi di compilazione e rilascio per supportare l'integrazione continua/distribuzione continua delle applicazioni.

    • Azure Boards è uno strumento di gestione del lavoro basato sul Web che supporta procedure Agile come Scrum e Kanban.

    • Azure Repos è uno strumento di controllo della versione che supporta il sistema di controllo della versione distribuita Git e il sistema di controllo della versione di Team Foundation.

    • Piani di test di Azure è una soluzione di gestione dei test basata su browser che fornisce funzionalità necessarie per i test manuali pianificati, i test di accettazione degli utenti, i test esplorativi e la raccolta di feedback dagli stakeholder.

    • Azure Artifacts viene usato per consentire agli sviluppatori di condividere in modo efficiente il codice e gestire i pacchetti.

  • GitHub Actions per Azure è uno strumento che è possibile usare per automatizzare i processi CI/CD. Si integra direttamente con Azure per semplificare le distribuzioni. È possibile creare flussi di lavoro che compilano e testano ogni richiesta pull nel repository o distribuiscono richieste pull unite nell'ambiente di produzione.

  • GitHub Projects è uno strumento di gestione del lavoro che è possibile usare per creare bacheche Kanban, report, dashboard e altre funzioni.

  • Gli strumenti con poco codice e senza codice includono:

  • I modelli di Azure Resource Manager e Bicep sono strumenti nativi di Azure che è possibile usare per distribuire IaC. Terraform è un altro strumento IaC supportato da Azure che è possibile usare per distribuire e gestire l'infrastruttura.

  • Visual Studio è uno strumento di sviluppo affidabile che si integra con Azure e supporta molti linguaggi.

  • GitHub Copilot è un servizio di intelligenza artificiale che funge da programmatore di coppie e fornisce suggerimenti di stile di completamento automatico durante il codice. Copilot è disponibile come estensione in Visual Studio e diversi altri strumenti di sviluppo.

  • Test di carico di Azure è un servizio di test di carico completamente gestito che è possibile usare per generare un carico su larga scala simulando il traffico per le applicazioni, indipendentemente dalla posizione in cui sono ospitate.

Allineamento dell'organizzazione

Cloud Adoption Framework per Azure fornisce linee guida generali e consigli per l'assegnazione di tag e la denominazione delle risorse di Azure, nonché regole specifiche ed esempi per diversi tipi di risorse.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa