Condividi tramite

Raccomandazioni per la standardizzazione di strumenti e processi

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

OE:04 Ottimizza i processi di sviluppo software e di garanzia della qualità seguendo pratiche comprovate nel settore per sviluppo e test. Per una designazione univoca dei ruoli, standardizza le pratiche tra componenti quali strumenti, controllo del codice sorgente, modelli di progettazione delle applicazioni, documentazione e guide di stile.

Questa guida descrive le raccomandazioni per definire gli standard per gli strumenti e i processi di sviluppo software. La definizione di pratiche coerenti conduce a un team del carico di lavoro efficiente e a un lavoro di alta qualità. I team ad alte prestazioni utilizzano strumenti e processi comprovati nel settore per ridurre al minimo sforzi inutili 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 standard che aiutano a ottimizzare le pratiche di sviluppo, prendi in considerazione le seguenti raccomandazioni.

Usare strumenti ben noti e maturi disponibili sul mercato

Usa strumenti ben noti e maturi pronti all'uso e standardizza il loro utilizzo. Team di tecnici altamente efficienti adottano gli strumenti migliori della categoria. 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. Considera il tempo e l'impegno necessari per sviluppare le tue soluzioni rispetto alle funzionalità fornite dagli strumenti premium. Considera i costi una tantum rispetto ai costi ricorrenti. Nella maggior parte dei casi, gli strumenti pronti all'uso forniscono un valore maggiore al tuo 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 formati come sviluppatori, di contribuire alla gestione del carico di lavoro. Gli strumenti IA possono rivelarsi utili riguardo a sviluppo, revisione e ottimizzazione del codice.

Standardizzare la strategia di diramazione

Scegliere un modello basato su trunk quando possibile. Il branching basato su trunk mantiene sincronizzato il team di sviluppo del flusso di lavoro e incoraggia la delivery continua. 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 monitorare facilmente la velocità, visualizza gli indicatori KPI utilizzando dashboard o altri strumenti di reporting.

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

Standardizza il modo in cui il team del carico di lavoro scrive, revisiona e documenta il codice utilizzando una guida di stile. Uno stile standard semplifica la collaborazione e agevola l'onboarding di nuovi sviluppatori. Per lavorare in modo efficace, i nuovi sviluppatori devono sapere come opera il team del carico di lavoro. Una guida di stile con standard chiaramente definiti può facilitarne il processo di formazione. 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 responsabile 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 gestite tramite controllo delle versioni.

Nel tuo ADR, includi:

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

  • Il contesto del processo decisionale, come il problema che è stato affrontato.

Implementare gli standard per affrontare il debito tecnico

Adotta una mentalità in cui il debito tecnico è intenzionale e necessario per le consegne del tuo team. Questo approccio spinge il tuo team a considerare e a colmare regolarmente il debito tecnico per evitarne l’accumulo. Colma il debito tecnico come attività ricorrente periodica nel backlog.

Supponiamo, ad esempio, che il team abbia standardizzato su 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 operativo a supportare due tecnologie, poiché non riescono a passare completamente senza intoppi. 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 l'applicazione della versione ai vostri 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. Scegli i modelli che avvantaggiano il tuo 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 i test

Implementa un approccio di spostamento a sinistra per i test eseguendo test unitari nelle prime fasi e spesso durante il processo di sviluppo. I test frequenti in ogni ambiente di sviluppo aiutano gli sviluppatori ad acquisire fiducia nelle loro applicazioni. Per aiutarti a creare la tua strategia di test con un approccio di spostamento a sinistra, considera i seguenti principi:

  • Scrivere test al livello più basso possibile. Preferisci i test con il minor numero di dipendenze esterne ed eseguili come parte della build.

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

  • Progettare il carico di lavoro per i test. Quando sviluppi l'applicazione, fai in modo che la testabilità sia 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, la quale si basa sulla proprietà del carico di lavoro. Il team di lavoro è responsabile dei propri test e non deve affidarsi ad altri team per testare il loro codice.

  • Automatizzare i test il più possibile. Il codice automatizzato agevola il lavoro del team del carico di lavoro e garantisce una qualità costante.

Implementare una varietà di tipi di test, come il test unitario, il test di fumo, il test di integrazione e il test di accettazione. Per un'analisi approfondita di questi tipi di test, consultare la sezione relativa ai test della guida alla raccomandazione della catena di approvvigionamento del carico di lavoro.

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 nel portale di Azure, In PowerShell, nell'interfaccia della riga di comando e nelle 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 dismissione, 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 include le soluzioni seguenti:

    • Azure Pipelines offre servizi di build e rilascio per supportare il CI/CD 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 compagno di programmazione e fornisce suggerimenti di completamento automatico mentre scrivi 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 aziendale

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 di Eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo di Eccellenza operativa