Accelerare il ciclo di vita del rilascio con il percorso di distribuzione: parte 2

Poiché le aziende adottano il cloud nativo e tutto sotto forma di codice, il percorso dal codice alla produzione è diventato un aspetto fondamentale per offrire valore ai clienti. Questo processo, spesso definito “percorso di implementazione”, comprende una serie di passaggi e decisioni complessi che possono avere un impatto significativo sulla capacità di un’organizzazione di fornire software in modo efficiente, affidabile e su larga scala.

Il primo post di questa serie esplora le complessità e scopre le strategie e le modalità dello stato target per ottenere un percorso di implementazione fluido ed efficace.

Questo post approfondisce l’argomento e fornisce un modello di maturità e elementi costitutivi che aiutano le aziende ad accelerare il ciclo di vita della catena di fornitura del software nel panorama in continua evoluzione dello sviluppo di software aziendale nativo del cloud.

Percorso per implementare la roadmap

Per realizzare un percorso accelerato di implementazione, ci sono diverse parti in movimento e parti interessate che devono unirsi. Raccomandiamo una tabella di marcia in 4 fasi per l’implementazione, come mostrato nella figura seguente.

Fase 1: automazione dello sviluppo

L’automazione dell’infrastruttura (IaC) e l’automazione della pipeline sono indipendenti all’interno del team di sviluppo, il che rende l’automazione un ottimo punto di partenza. In questa fase, l’attenzione è rivolta alla creazione di un catalogo aziendale di modelli di integrazione continua, distribuzione e test (CI/CD/CT) e Ops con le necessarie integrazioni di strumenti per automatizzare le attività principali di sviluppo e test. Data la complessità aziendale, la parte più difficile di questa fase è l’automazione delle funzionalità di test (in cui la preparazione dei dati di test e l’esecuzione dei casi di test su più sistemi sono per lo più semi-automatizzate). Il Cloud Capability Center (CCC), o il team principale equivalente, svolge un ruolo significativo nel guidare il cambiamento con i team delle applicazioni e della piattaforma.

Fase 2: istituzionalizzare il modello basato su modelli

CCC (o il suo equivalente) collabora con il comitato di architettura per stabilire una suite di modelli ripetibili (inclusi modelli atomici che rappresentano singoli servizi cloud, nonché modelli applicativi compositi comprendenti più servizi cloud). Il processo di revisione dell’architettura (insieme ad altri processi di revisione correlati) viene modificato per istituzionalizzare rappresentazioni di architettura incentrate sui modelli con un backlog stabilito per diversi gruppi (come l’ingegneria della piattaforma e CCC) per costruire questi modelli come codice. Ciò aiuta l’adozione e l’accelerazione. Nel corso del tempo, le applicazioni rappresentate appaiono come un insieme di modelli che standardizzano i modelli di sviluppo a tutti i livelli. Inoltre, team come la continuità aziendale, la resilienza e la sicurezza sfrutteranno questi modelli (ad esempio, architetture multi-regione altamente disponibili) per riconoscere e accelerare i cancelli di approvazione con un approccio standardizzato. La chiave di questo allineamento è la co-creazione di questi modelli tra le organizzazioni partecipanti.

Fase 3: integrazione self-service e interfunzionale

Ci sono molte organizzazioni che vogliono vedere che le applicazioni cloud seguano le loro indicazioni e le migliori pratiche. Questa fase si concentra sull’integrazione di team interfunzionali (come sicurezza, conformità e FinOps) attraverso automazione, strumenti, modelli codificati o opzioni self-service. Ciò si basa sulle fasi precedenti per enfatizzare una partecipazione significativa tra i team. Gli aspetti chiave di questa fase sono:

• Costruisci e allinea modelli di alta disponibilità con i team di resilienza in cui le revisioni vengono accelerate, dimostrando l’aderenza a questi modelli.
• Codifica i requisiti di sicurezza e conformità nei modelli e proteggili sulla piattaforma come un insieme di policy.
• Affrontare la convalida integrando strumenti, come scansioni di vulnerabilità, strumenti di controllo delle policy (come Cloud Formation Guard per AWS) e sicurezza dei container con le pipeline che seguono i principi dello spostamento a sinistra.
• Arruolare team di record aziendali per studiare una serie di modelli di classificazione e conservazione dei dati e arruolare team FinOps per valutare l’appropriata codifica e il rispetto delle quote.
• Costruisci modelli di integrazione AuthN/AuthZ che astraggono le sfumature e standardizzano l’autenticazione e l’autorizzazione di applicazioni, dati e servizi.
• Automatizza il firewall generando file di risorse dall’esecuzione IaC e importandoli nei sistemi firewall come descritto qui.
• Catalogo aziendale di Platform Engineering che offre molteplici funzionalità self-service.

Fase 4: percorso automatizzato per la distribuzione

Questa fase si concentra sulla decentralizzazione e sul disaccoppiamento di vari gruppi aziendali integrandoli contemporaneamente attraverso l’automazione e DevSecOps. Un esempio è l’automazione dei processi di gestione delle modifiche, inclusa la generazione automatizzata di note di rilascio, in cui il sistema costruisce autonomamente elenchi di controllo completi per la revisione delle modifiche aggregando dati provenienti da più sistemi interconnessi. Ciò si traduce in fiducia, efficienza e accuratezza nelle recensioni. Questo approccio olistico rappresenta un salto significativo in termini di efficienza operativa e mitigazione del rischio per l’azienda.

Percorso di distribuzione: elementi costitutivi del modello cloud-native

Esploriamo alcuni casi d’uso che mostrano il percorso per implementare l’accelerazione.

Caso d’uso 1: codifica IaC incentrata sulla persona

La codifica IaC basata su persone e modelli può accelerare sia le fasi di sviluppo che quelle di revisione. La figura seguente rappresenta più parti interessate in un’azienda che hanno preoccupazioni e requisiti diversi per i carichi di lavoro nativi del cloud.

I team di prodotto impiegano molto tempo di sviluppo per codificare manualmente ciascuna di queste preoccupazioni, per non parlare del tempo necessario alle parti interessate per rivedere manualmente ciascuna area. Codificarli in modelli discreti o compositi rafforzati fornisce ai team di prodotto il giusto codice Bootstrap e l’accelerazione, creando fiducia da parte delle parti interessate e revisione dell’efficienza.

Caso d’uso 2: sicurezza e convalida delle policy con spostamento a sinistra

Automatizza la sicurezza, la conformità e altre policy per l’infrastruttura come parte della pipeline CI/CD. Ciò garantisce che l’infrastruttura distribuita sarà allineata alle policy aziendali anche prima della sua implementazione. Esistono diversi approcci forniti dai fornitori di servizi cloud e strumenti open source in grado di raggiungere questo obiettivo (tra cui Checkov, Cloud Formation Guard e cfn-nag). In genere, i team di sicurezza codificano le regole di convalida delle policy e i team di prodotto integrano la convalida delle policy all’interno delle pipeline CI/CD/CT prima che l’infrastruttura venga fornita all’ambiente cloud.

Caso d’uso 3: raccolta automatizzata di prove di conformità per le revisioni

I team interfunzionali della piattaforma cloud, della sicurezza e della conformità creano un’automazione che consente la raccolta di prove, accelerando le revisioni della sicurezza e della conformità. Ciò in genere richiederebbe l’utilizzo delle API cloud per interrogare informazioni dalle risorse cloud distribuite, nonché la creazione di prove e comportamenti di conformità. Tali funzionalità potrebbero consentire ai team di prodotto di eseguire tale automazione in un modello self-service o tramite pipeline DevOps e identificare il livello di conformità, oltre ad acquisire automaticamente le prove delle revisioni. Il livello di maturità aumenta quando l’acquisizione delle prove viene eseguita automaticamente e la revisione avviene in modalità completamente a mani libere.

Caso d’uso 4: modelli integrati e toolkit pipeline

I modelli compositi nativi del cloud come le API AWS Active-Active Serverless richiedono l’unione di diversi modelli discreti. Questi modelli includono:

1. Servizi cloud, come Route53, API Gateway, Lambda, Dynamo DB, IAM, CodeDeploy, CodeBuild, CodePipeline e CodeCommit.
2. Requisiti non funzionali, come AuthN/AuthZ, distribuzione attivo-attivo multiregione, sicurezza a riposo e in transito, tracciamento, registrazione, monitoraggio, dashboard, avvisi, automazione del failover e controlli di integrità.
3. Strumenti aziendali integrati, tra cui qualità del codice, SAST, DAST, avvisi, gestione dei test, monitoraggio e pianificazione.

Una soluzione con un solo clic consentirebbe ai team di prodotto di selezionare il modello giusto, che creerà il codice Bootstrap necessario che integra diversi modelli codificati come descritto nei casi d’uso precedenti.

Percorsi di implementazione: approccio di consegna

Affinché un modello di distribuzione realizzi il percorso di implementazione, il CCC (o equivalente) deve collaborare con più gruppi organizzativi, come mostrato nella figura seguente.

Il percorso per implementare il modello di consegna comprenderebbe i seguenti passaggi:

1. Definire l’intero percorso per il processo di distribuzione attraverso una serie di fasi del ciclo di vita dell’applicazione, attività, risultati finali e gruppi dipendenti coinvolti.
2. Definisci e organizza più squadre concentrandoti su diversi aspetti del percorso da schierare.
3. Pianificare un modello flessibile all’interno delle squadre per coinvolgere gruppi di supporto come richiesto.
4. Crea un backlog per ciascuna delle squadre del Cloud Capability Center e avvia lo sviluppo delle capacità.
5. Allinearsi al modello di maturità in 4 fasi in modo che le aziende possano monitorare la maturità.
6. Stabilire team di prodotto e stakeholder rilevanti come parte del perfezionamento e della definizione delle priorità del backlog.
7. Garantire che l’adozione dell’automazione sia costantemente focalizzata. Il successo del percorso di implementazione dipende dalla creazione dell’automazione e dalla sua adozione.
8. Costruisci una gestione centrale della conoscenza e una gestione della pianificazione attorno al percorso da implementare.
9. Rendi più semplice per i team di prodotto incorporare queste attività nei loro piani di consegna (con il monitoraggio dei progetti e strumenti di collaborazione agile come Jira).
10. Costruire un sistema di misurazione per il percorso di implementazione degli SLA di gate di fase e monitorare continuamente il miglioramento degli SLA (man mano che il percorso di implementazione delle capacità matura in un periodo).

Considerando il motivo per cui la trasformazione del cloud potrebbe non produrre pieno valore e identificando l’accelerazione del ciclo di vita del rilascio come una sfida chiave, ciò restringe l’attenzione al percorso di implementazione. Il percorso di implementazione può essere un veicolo comune che consente a più gruppi di accelerare l’intero ciclo di vita della catena di fornitura del software oltre l’accelerazione del ciclo di vita di sviluppo e test che esiste oggi. È stata definita una tabella di marcia in 4 fasi in cui le fasi iniziali si concentrano su DevSecOps e l’adozione di modelli, mentre le fasi avanzate maturano verso la cultura dell’ingegneria del prodotto. Si consiglia ai team di prodotto di collaborare con i gruppi aziendali partecipanti in modo decentralizzato per sfruttare l’automazione e il self-service. Il modello di maturità incoraggia le organizzazioni a crescere in modo incrementale iniziando in piccolo e il nostro approccio alla fornitura porta risultati prevedibili in questo percorso complesso.

Scopri come accelerare l’agilità e la crescita aziendale