Introduzione ad Azure DevOps release management

di , in DevOps,

Nell'articolo introduttivo di questo canale, dedicato in generale a DevOps e più nel dettaglio ad Azure DevOps, abbiamo visto come dovrebbe funzionare, in linea di massima, un processo standard di sviluppo del codice. Sebbene ci possano essere notevoli differenze tra quello che può essere considerato un approccio didattico rispetto a quella che è la realtà in cui lavoriamo, in linea di principio vale a prescindere il seguente concetto derivante proprio da DevOps stesso: da quando gli sviluppatori prendono in carico l'attività a loro assegnata per l'elaborazione a quando la funzionalità verrà rilasciata, deve intercorrere meno tempo possibile. Solo così si potrà rilasciare, con alta frequenza, valore ai nostri clienti finali, siano essi incrementi di prodotto o nuovi unit test sviluppati.

Gli strumenti che possono venirci comodi per realizzare quanto descritto sono molteplici ma, come abbiamo già visto in precedenza, il nostro compito sarà focalizzarci su Azure DevOps, la suite con tutti gli strumenti integrati per board, pipeline, test e molto altro, creata da Microsoft stessa.

Partendo da quanto analizzato nell'articolo introduttivo, possiamo dare per scontato che abbiamo già a disposizione tutte le conoscenze necessarie per creare un vero e proprio processo di build, in grado di produrre applicazioni pronte da essere distribuite. Le build vengono compilare in regime di continuous integration, ovvero il prima possibile, ad ogni modifica fatta dagli sviluppatori stessi, quindi è fondamentale avere a disposizione un supporto che consenta di distribuire con altrettanta semplicità e rapidità, quanto già creato dai processi di build.

Nell'area riservata ad Azure DevOps Pipelines, Microsoft rende disponibile la sezione "Releases" per definire quelle che sono chiamate le pipeline di deployment (o processi di rilascio). Questa parte è separata rispetto alle pipeline classiche costruite tramite l'interfaccia grafica che abbiamo visto in precedenza: infatti, questa sezione è dedicata al release management, ovvero contiene tutti gli strumenti che possono non solo descrivere il processo, ma anche aiutarci nel definire strategie di rilascio, ordine di esecuzione, gestione degli artefatti, gestione delle approvazioni e così via. La complessità delle operazioni svolte ogni qualvolta un processo di deployment viene avviato, è identificabile nell'immagine seguente ma, per fortuna, è Azure DevOps a gestire tutta l'integrazione per noi, lasciandoci solamente spazio per definire il processo secondo le nostre logiche di business.

Quello che si vuole realizzare, solitamente, è un rilascio "safe" basato su diversi ambienti:

  • Dev: rappresenta l'ambiente di sviluppo ed è quello più soggetto a malfunzionamenti;
  • QA: rappresenta l'ambiente dove la maggior parte dei test viene eseguita;
  • Pre-produzione o staging: identico all'ambiente di produzione in tutto e per tutto, viene solitamente utilizzato per simulare test di upgrade;
  • Produzione: rappresenta l'ambiente utilizzato realmente dai vari clienti.

Chiaramente l'approccio può variare notevolmente secondo le esigenze di ciascun progetto: Microsoft, Netflix, StackOverflow e molti altri usano solo l'ambiente di produzione, ma questo è frutto di notevole esperienza, alta qualità del codice e anni di automazione alle spalle. Usare solo un ambiente piuttosto che quattro, come nel caso evidenziato, non è detto che porti innumerevoli benefici poiché tutto, come sempre, dipende da ciò che si sta realizzando.

Rimanendo sul caso più semplice dei quattro ambienti descritti, l'artefatto, ovvero l'output generato dal processo di build, verrà processato dall'ambiente di Dev fino ad arrivare, potenzialmente, fino all'ambiente di produzione: per ciascuno degli step (o stage) intermedi, verrà infatti applicato un controllo qualitativo e autorizzativo, perciò se l'applicazione rilasciata in un determinato ambiente non dovesse superare i requisiti minimi richiesti, il processo di deployment si potrà interrompere, altrimenti proseguirà e verrà eseguito un deployment nell'ambiente successivo, fino ad arrivare alla produzione.

Vediamo ora con questo articolo di approfondimento come la parte di Azure DevOps release management ci consente di realizzare pipeline complesse di rilascio per un'applicazione ASP.NET Core classica e quali sono gli accorgimenti che possiamo mettere in piedi per applicare controlli di qualità sfruttando metriche e autorizzazioni sulla pipeline stessa.

5 pagine in totale: 1 2 3 4 5
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

Introduzione ad Azure DevOps release management
| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

Top Ten Articoli

Articoli via e-mail

Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!

In primo piano

I più letti di oggi

In evidenza

Misc