Release software: Pianificazione delle attività di rilascio del software

Release software: Pianificazione delle attività di rilascio del software

Release del software

L’acceptance test stage, rappresenta un punto di arrivo parziale della pipeline. Giunto in questa fase e superandola con successo, il software è a tutti gli effetti un candidato idoneo alla release, essendo già pronto all’utilizzo da parte dell’utente finale. In molti processi di release, però, si preferisce inserire un ulteriore fase di testing manuale. Più che uno stage determinante per il rilascio definitivo, il manual testing si presenta come una ulteriore validazione dei test automatici svolti nella fase precedente. Il ruolo del tester umano è quello di verificare, manualmente, il soddisfacimento degli acceptance criteria definiti e verificati già in maniera automatica. Una sorta di prova del nove, dunque, in cui il tester può essere visto come l’utente finale che partecipa attivamente al deployment del software.

Release software: Pianificazione delle attività di rilascio del software

Oltre alla fase di manual testing, prima della release definitiva, possono essere inseriti altri step ulteriori. Ne è un esempio la validazione di requisiti non funzionali, quali policy di sicurezza o di altro genere, cui il servizio deve essere conforme: si parla in questo caso di nonfunctional testing. Se invece si è meno interessati alla compliance e si preferisce capire come il sistema reagisce alla variazione del carico di lavoro in produzione, in questo caso si effettuano dei test di capacità (capacity testing). E’ chiaro dunque che, successivamente al commit stage e l’acceptance test stage, indispensabili in qualunque processo di release automation, aumenta il grado di libertà circa la costruzione della pipeline. Ciò varia in relazione alle esigenze e ai requisiti da soddisfare, dipendentemente dal campo applicativo in cui il software dovrà essere utilizzato.

Giunti a questo punto, siamo in grado di:

  • Creare un piano di release gestito in collaborazione da ogni risorsa, tra cui sviluppatori, tester, sistemisti e chiunque altro coinvolto nello sviluppo, manutenzione e delivery del software
  • Minimizzare il livello di errore, automatizzando tutto quello che è possibile all’interno del processo di deployment
  • Simulare le procedure di un ambiente di produzione, testando configurazioni e build in ambienti production-like
  • Migrare facilmente il software in produzione nel caso di aggiornamenti, ripristinare vecchie release in caso di problemi

Alla luce di quanto detto, l’ultimo stage della pipeline, quello della release vera e propria, non è altro che un naturale risultato del corretto funzionamento e della corretta implementazione degli stage precedenti. Nell’immagine qui di seguito viene riportata una visione d’insieme della deployment pipeline, in cui vengono inseriti i vari attori e i vari passaggi effettuati prima di giungere al risultato finale.

Riepilogando, in ordine, i vari step:

Release software: Pianificazione delle attività di rilascio

Qualcuno tra gli sviluppatori esegue un commit sul sistema di version control:

  1. Il server di continuous integration avvia l’esecuzione automatica della pipeline: inizio del commit stage
  2. Completato il commit stage con successo, gli artifacts vengono automaticamente storicizzati in un apposito repository
  3. Il server di continuous integration recupera gli artifacts, creati nello step precedente, dal repository e riproduce automaticamente un ambiente production-like
  4. Il server di continuous integration lancia automaticamente l’esecuzione degli
    acceptance tests, all’interno dell’ambiente di testing riprodotto
  5. Superando con successo i test automatici, l’applicazione viene marcata come idonea per la release
  6. La persona incaricata al testing manuale, può riprodurre manualmente l’ambiente di testing recuperando gli artifacts creati in seguito al commit stage. Eseguito il manual testing, l’applicazione prosegue il suo percorso di validazione
  7. Il server di continuous integration può, a questo punto, eseguire il software direttamente nell’ambiente di produzione. Tuttavia, esso ancora non è stato marcato come rilasciato (released) ma viene semplicemente sottoposto a dei test capacitivi
  8. A questo punto, in assenza di problemi, la produzione è approvata dai business manager che la dichiarano ufficialmente released.

Release software - Pianificazione delle attività di rilascio del software aziendale
Release software – Pianificazione delle attività di rilascio del software aziendale

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *