Raccomandazioni per la standardizzazione di strumenti e processi

  • Articolo

Si applica a questo elenco di controllo di Eccellenza operativa di Azure Well-Architected Framework:

OE:04 Ottimizzare i processi di sviluppo software e di garanzia della qualità seguendo le procedure comprovate del settore per lo sviluppo e i test. Per la designazione di ruoli non ambigui, standardizzare le procedure tra i componenti, ad esempio 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 i consigli per definire gli standard per gli strumenti e i processi di sviluppo software. La definizione di procedure coerenti comporta un team di carico di lavoro efficiente e un lavoro di alta qualità. I team con prestazioni elevate usano strumenti e processi comprovati dal settore per ridurre al minimo gli sforzi 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 dal settore anziché sviluppare soluzioni interne. Per ottimizzare ulteriormente le procedure, adottare strumenti a basso codice e no-code. Questi strumenti consentono di concentrarsi sulle attività dell'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 i consigli seguenti.

Usare strumenti ben noti e maturi

Usare strumenti ben noti e maturi e standardizzare il loro uso. I team di ingegneria altamente efficaci adottano i migliori strumenti in 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 la distribuzione continua (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. 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 possono fornire diverse funzioni. Assicurarsi di comprendere le funzionalità degli strumenti e le relative limitazioni in modo da soddisfare 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à fornite dagli strumenti Premium. Prendere in considerazione i costi una sola volta rispetto ai costi ricorrenti. Nella maggior parte dei casi, gli strumenti off-the-shelf offrono un valore più elevato al team.

Usare strumenti a basso codice, no-code e intelligenza artificiale quando è pratico. Gli strumenti a basso codice e no-code risparmiano tempo per sviluppatori esperti 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 agli sviluppatori di contribuire all'operazione 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 branching

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

Valutare le metriche per quantificare l'efficacia dello sviluppo

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

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

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

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

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

Per aiutare gli stakeholder e il team del carico di lavoro a tenere traccia 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, revisioni e documenti codice

Standardizzare il modo in cui il team del carico di lavoro scrive, esamina e documenta codice usando una guida di stile. Uno stile standard semplifica la collaborazione e aiuta a eseguire l'onboarding di nuovi sviluppatori. Per lavorare in modo efficace, i nuovi sviluppatori devono conoscere il funzionamento del team del carico di lavoro. Una guida di stile con standard chiaramente definiti può semplificare il processo di training. Nella guida allo 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 stile, qualità, gestibilità, progettazione e altri problemi. Per l'infrastruttura come codice (IaC), è possibile usare Checkov o Terrascan per Terraform.

Per garantire coerenza ed evitare potenziali confusioni, la guida allo 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 loro redditività e sostituire le tecnologie esistenti quando appropriato.

Usare i record decisionali dell'architettura (ADR) per mantenere un record cronologico delle decisioni di progettazione del team di carico di lavoro. Le adR consentono ai team di mantenere una nuova comprensione del carico di lavoro. Aiutano anche i nuovi membri del team a conoscere le decisioni di progettazione effettuate durante il ciclo di vita del carico di lavoro. Assicurarsi che le ADR siano controllate dalla versione.

In 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 nelle decisioni.

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

Implementare gli standard per affrontare il debito tecnico

Adottare una mentalità che il debito tecnico è intenzionale e necessario per i risultati finali del team del carico di lavoro. Questa mentalità motiva il team a considerare e risolvere regolarmente il debito tecnico per evitare l'accumulo. Risolvere il debito tecnico come attività ricorrente regolarmente nel backlog.

Si supponga, ad esempio, che il team sia standardizzato in una libreria. Nel tempo è necessario passare a una libreria diversa per una nuova funzionalità nel carico di lavoro. Tale transizione potrebbe comportare un debito tecnico. Spesso, le transizioni come questa 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 completare la transizione perché quando il carico di lavoro ottiene la nuova funzionalità, gli stakeholder sono soddisfatti e sono meno probabili considerare il debito tecnico.

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

Standardizzare il modo in cui si applica il controllo delle versioni agli artefatti e il modo in cui il controllo delle versioni viene esposto internamente ed esterno. 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 dal settore per garantire che l'applicazione sia affidabile, efficiente e sicura. Usare questi modelli per risparmiare tempo e sforzo rispetto allo sviluppo di soluzioni personalizzate per l'applicazione. Scegliere i modelli che consentono di trarre vantaggio dal carico di lavoro. Esaminare regolarmente i modelli di progettazione per assicurarsi di usare i modelli corretti durante l'evoluzione del carico di lavoro.

Implementare un approccio 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 a sinistra di turno, prendere in considerazione i principi seguenti:

  • Scrivere test al livello più basso possibile. Privilegia i test con le dipendenze esterne più poche e esegue test come parte della compilazione.

  • Scrivere test una sola volta ed eseguire test ovunque, tra cui 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 il 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à dei test, basata sulla proprietà del carico di lavoro. Il team del carico di lavoro possiede i test e non deve basarsi su altri team per testare il codice.

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

Per indicazioni dettagliate sull'implementazione di una strategia di test DevOps, vedere Test di maiusc a sinistra con unit test.

Richiedere 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 eccezione. Per altre informazioni, vedere Guida al ciclo di vita dello sviluppo della sicurezza.

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

L'implementazione di tag e convenzioni di denominazione è una procedura consigliata per la gestione e l'organizzazione delle risorse di Azure. I tag e le convenzioni di denominazione consentono di identificare, classificare e raggruppare le risorse in base agli attributi comuni, ad esempio ambiente, applicazione, proprietario o centro costi. Consentono inoltre 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 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 provisioning, rimozione, backup e 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 dei 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 raggruppa le soluzioni seguenti:

    • Azure Pipelines offre servizi di compilazione e rilascio per supportare la 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.

    • Azure Test Plans è una soluzione di gestione dei test basata su browser che offre funzionalità necessarie per test manuali pianificati, test di accettazione utente, test esplorativi e raccolta di feedback da parte degli stakeholder.

    • Gli artefatti di Azure vengono usati 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 schede Kanban, report, dashboard e altre funzioni.

  • Gli strumenti a basso codice e no-code 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 come codice. Copilot è disponibile come estensione in Visual Studio e diversi altri strumenti di sviluppo.

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

Elenco di controllo Di eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo Di eccellenza operativa