Guida: Gestione delle versioni del software per piccoli team

Formalizzazione del processo di gestione del rilascio (se presente)

In alcune configurazioni del team, in particolare quelle che si trovano nelle startup, non ci sono DevOps, né ingegneri dell'infrastruttura, per fornire supporto durante il rilascio di una nuova versione del prodotto.

Inoltre, a differenza delle grandi aziende burocratiche con processi formali definiti, il team CTO o Head of Software Development in una startup spesso non è a conoscenza della complessità del processo di gestione del rilascio del software; alcuni sviluppatori dell'azienda potrebbero essere a conoscenza dei complessi dettagli del processo, ma non tutti. Se questa conoscenza non è documentata a fondo , credo che potrebbe creare confusione.

In questo articolo cercherò di fornire alcuni suggerimenti su come formalizzare il processo di rilascio, in particolare dal punto di vista dello sviluppatore.

Immettere l'elenco di controllo della versione del software

Potresti avere familiarità con l'idea di una checklist per alcune operazioni, come da Checklist Manifesto , un libro di Atul Gawande. Credo che un processo di rilascio formale (come molte altre attività nel mondo dello sviluppo software) offra agli sviluppatori l'opportunità di implementare questo protocollo. Un elenco di controllo del processo di rilascio dovrebbe essere conservato in un documento condiviso, preferibilmente sotto forma di wiki collaborativo o foglio di lavoro su Google Drive.

Condividendo questo documento vitale con il team e concedendo autorizzazioni di modifica, ogni membro ha accesso al processo di rilascio formalmente definito. Questo permette loro di capire come funziona il processo. Inoltre, a seguito di discussioni con altri membri del team, consente al team di migliorarlo di tanto in tanto. Ciò dovrebbe portare trasparenza e consentire all'intero team di avere accesso in tempo reale a ciò che sta accadendo durante il rilascio, quali passaggi sono stati completati e da chi.

Osservando questo foglio di calcolo, le parti interessate possono decidere tra "GO" e "NO GO", in base all'esito dei passaggi. Ad esempio, se uno stress test va storto in un ambiente di test, in base all'evento il project manager potrebbe decidere di annullare il rilascio di produzione.

Passaggi consigliati da utilizzare come base

In questa sezione, proporrò alcuni passaggi che puoi utilizzare per creare la tua lista di controllo per il tuo processo di rilascio. Alcuni di questi passaggi non sono assolutamente obbligatori . Ogni app è diversa e ogni organizzazione funziona in modo diverso, quindi sentiti libero di adattarti e apportare modifiche che si adatteranno meglio al tuo flusso di lavoro.

1. Crea un ramo di rilascio

È probabile che tu abbia familiarità con il concetto di Git Workflow o con l'idea di rami di rilascio, un argomento che è stato spiegato in un precedente post del blog.

Idealmente, dovresti avere almeno tre rami:

• master : questo dovrebbe riflettere lo stato attuale di ciò che è nell'ambiente di produzione. Ogni nuovo commit su master dovrebbe comprendere solo una nuova versione.
• sviluppo : questo ramo dovrebbe contenere le funzionalità imminenti completate (e testate). È comune creare un ramo separato per ciascuna funzionalità e quindi unirlo per svilupparlo quando la funzionalità è pronta.
• release : i rami di rilascio sono una raccolta di commit pronti per essere inviati alla produzione, oltre ad alcune correzioni di bug minori relative al rilascio.

Si noti che i rami di rilascio devono essere rimossi una volta completato il rilascio, quindi questi rami vengono creati e distrutti continuamente, a differenza di master o development , che sono sempre gli stessi.

Per creare un nuovo ramo di rilascio , dal ramo di sviluppo nel tuo terminale git, digita:

$ git checkout -b release/xyz

È conveniente utilizzare una convenzione di denominazione, come quella definita sopra, sostituendo xyz con il numero di versione major.minor.patch in base alle tue esigenze (è una politica che dovresti definire all'interno del tuo team e attenerti ad essa).

È anche importante dire che se si codificano alcune correzioni di bug nel ramo di rilascio, non si dovrebbe dimenticare di unirle nuovamente per sviluppare . Lo scopo principale del ramo di rilascio è avere uno snapshot di anteprima di come dovrebbe comportarsi l'app dopo che è entrata in produzione.

2. Versione ad urto

Il passaggio successivo sarebbe aumentare (modificare o aumentare) il numero di versione sul ramo di rilascio .

Dovresti aprire AndroidManifest.xml / package.json / pom.xml / o ovunque la versione dell'app sia archiviata nel tuo progetto (YMMV), aggiornare il numero di versione e quindi eseguire il commit delle modifiche nel ramo di rilascio corrente.

È importante aggiornare il numero di versione per due motivi.

In primo luogo, puoi tracciare e mappare le funzionalità introdotte in ciascuna versione e, in secondo luogo, sarai a conoscenza della versione che stanno utilizzando nel caso in cui debbano eseguire una risoluzione dei problemi o contattarti per assistenza. Se stai creando un'app mobile, il numero di versione che stai aggiornando in questo passaggio viene solitamente visualizzato sul lato utente, nella sezione Informazioni o in Google Play o nell'App Store di Apple. Questo passaggio è anche una buona opportunità per aggiornare in base all'ambiente -file di configurazione (anche se suggerirei di tenerli in un repository separato), come fare in modo che il ramo punti al database di produzione o qualsiasi altra modifica necessaria al processo di compilazione.

Infine, si consiglia di inviare il ramo di rilascio all'origine, in modo che sia disponibile per gli altri sviluppatori:

$ git push -u origin release/xyz

3a. Unisci il ramo di rilascio al master e taggalo

Solo il ramo master deve essere distribuito per la produzione, quindi in questo passaggio è necessario unire il ramo di rilascio in master .

 $ git checkout master $ git merge --no-ff release/xyz $ git push

Il flag --no-ff è facoltativo, tuttavia se ne consiglia l'uso per forzare la creazione di un nuovo oggetto commit, anche se l'unione può essere completata usando la tecnica del fast forward.

Successivamente, è il momento di taggare la versione sul ramo principale :

$ git tag -a xyz -m 'description of new version, features or fixes included'

I tag sono utili perché stai conservando questo punto specifico della cronologia nel repository git e puoi tornare in seguito per ricreare un ramo separato di un tag particolare.

3b. Utilizzare una richiesta pull per unire il ramo di rilascio

Un'altra alternativa usata spesso consiste nell'usare una richiesta pull per unire il ramo di rilascio in master .

I vantaggi di questo approccio sono numerosi. Viene creato un nuovo spazio per la collaborazione, che il team può utilizzare per discutere vari problemi relativi al rilascio. Questo punto è un buon momento per aggiungere una porta aggiuntiva per incorporare un processo di revisione del codice, avendo più occhi per monitorare il codice che verrà introdotto e per discutere potenziali modifiche.

Alcuni strumenti che ti consentono di implementare richieste pull nei tuoi flussi di lavoro sono GitHub, Bitbucket e GitLab (unisci richiesta come la chiamano su quest'ultimo). Con questi strumenti, non si digitano i comandi git manualmente, ma si utilizza un'interfaccia web per impostare il ramo di origine ( release ) e il ramo di destinazione ( master ), quindi si aggiungono uno o più revisori, tutti essere in grado di scrivere commenti in linea su queste nuove modifiche, suggerire miglioramenti e così via.

Dopo che tutti i revisori hanno approvato la richiesta pull, puoi unire automaticamente le modifiche al master premendo un pulsante sull'interfaccia utente.

4. Distribuire Master nell'ambiente di produzione

È buona norma, in questa fase, fare in modo che un tester della tua squadra esegua un test del fumo (questo potrebbe essere definito in un elenco di controllo separato) prima di distribuire l'app. Un buon suggerimento è distribuire il ramo principale in un ambiente di test separato. Il tester può quindi eseguire alcune azioni di base per assicurarsi che nulla sia andato storto dopo l'unione nell'ultima build. Come condurre un test del fumo va oltre lo scopo di questo articolo, ma puoi trovare molto materiale sul web a riguardo. Il risultato del test del fumo può essere integrato nella checklist/foglio di calcolo del rilascio, documentando tutto ciò che è andato storto.

A questo punto, sei pronto per distribuire le modifiche e renderle attive. Vai avanti e distribuisci il ramo principale . Questo passaggio dipenderà dallo stack dell'infrastruttura in uso. Potrebbe comportare la connessione alla tua istanza Amazon EC2 per caricare la tua app, o il push a un telecomando Heroku o la connessione tramite ssh al tuo VPS per copiare la nuova versione o qualsiasi altro processo.

Dopo aver caricato l'app, assicurati che sia stata distribuita correttamente e che funzioni come previsto.

5. Unisciti di nuovo al ramo di sviluppo ed eliminazione del rilascio

Ora che il rilascio è quasi completato, ti consigliamo di unire il ramo di rilascio in developer , aggiornare il numero di versione su quest'ultimo e trasferire tutte le correzioni di bug apportate al ramo di sviluppo principale:

 $ git checkout develop $ git merge release/xyz

Ora è il momento di rimuovere il ramo di rilascio :

$ git branch -d release/xyz

6. Generazione del registro delle modifiche

Dovrebbe esserci un file nella radice del tuo progetto chiamato CHANGELOG.md (o un equivalente) in cui dovresti aggiungere una nuova voce ogni volta che c'è una nuova versione per documentare tutto ciò che è incluso in esso, come correzioni di bug, nuove funzionalità, problemi noti e qualsiasi altra informazione rilevante sotto forma di note di rilascio. Questo è davvero utile per utenti e collaboratori per vedere quali modifiche sono state apportate tra ogni versione (o versione) del progetto.

La voce del changelog include la data, il numero di versione e alcune note sulla versione. Le voci devono essere mantenute in ordine cronologico inverso. Ecco un semplice modello che ho utilizzato che puoi adattare al tuo progetto:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

Inoltre, questo passaggio può essere completamente automatizzato sia codificando uno script di base che attraversa il log git e genera automaticamente la voce del log delle modifiche, sia utilizzando uno strumento che fa lo stesso, come ad esempio:

• Github Changelog Generator, di skywinder,
• ReadmeGen di fojuth
• github-changes, di lalitkapoor

Tieni presente, tuttavia, che il grado di automazione che ottieni è direttamente proporzionale alla severità del formato del messaggio di commit. Credo che sia sempre buona norma concordare con il team un formato specifico per i messaggi di commit. Seguendo le linee guida sullo stile dei messaggi di commit, saranno più facili da analizzare e quindi più probabile che sarai in grado di automatizzare la generazione del log delle modifiche.

7. Comunicare con le parti interessate

Qui è dove normalmente faresti alcune delle seguenti operazioni:

• Fai sapere al team tramite uno strumento di messaggistica interno (ad esempio: Slack) che una nuova versione è stata completata. Consiglio di creare un nuovo canale (es: #releases ) al solo scopo di comunicare gli eventi relativi al rilascio. È facile aggiungere hook in un canale Slack per pubblicare un messaggio dopo che è stata eseguita un'azione.
• In alternativa, inviare un'e-mail alle parti interessate con un collegamento al log delle modifiche o il file del log delle modifiche allegato.
• Scrivi un post sul blog (se hai un blog per la tua app o prodotto) o un tweet.

È possibile intraprendere più azioni a seconda della natura dell'organizzazione. L'importante è non dimenticare di comunicare che è disponibile una nuova versione del tuo prodotto.

8. Ripulire il problema Tracker

Dopo l'esecuzione di una versione, probabilmente dovrai aggiornare lo stato di alcuni dei tuoi ticket per tenere traccia delle correzioni di bug o delle funzionalità attualmente in produzione. In genere, ciò comporta la modifica di alcuni tag (per i piccoli progetti utilizzo un tag in attesa di rilascio , che rimuovo al termine del rilascio).

Se utilizzi le pietre miliari per ogni nuova versione, probabilmente dovrai aggiornarne lo stato o contrassegnarle come completate. Alcuni rilevatori di problemi ti consentono persino di pianificare il rilascio e allinearlo agli sprint, monitorare se un bug sta bloccando un rilascio e altre informazioni utili.

Tutto dipende da come usi lo strumento. Voglio semplicemente sottolineare che il compito di aggiornare le informazioni nel tracker dei problemi dovrebbe essere incluso nella tua checklist di rilascio.

Informazioni sull'automazione del processo di rilascio

Il lettore potrebbe aver notato che, a parte il passaggio del registro delle modifiche descritto sopra, anche molti dei suddetti passaggi possono essere automatizzati.

La possibilità di automatizzare alcune parti del processo di rilascio è un'enorme vittoria e consente di risparmiare molto tempo. Suggerisco di creare script o di capire come automatizzare i singoli passaggi e quindi lavorare verso un obiettivo di consegna continua. La distribuzione continua può ridurre i rischi, i costi e il tempo che gli sviluppatori devono dedicare alla gestione del rilascio. Di conseguenza, sarai in grado di rilasciare più spesso ed essere più produttivo in termini di ore assegnate per lo sviluppo.

Il Santo Graal delle aziende DevOps è essere in grado di lanciare una nuova versione premendo un pulsante (o eseguendo un comando) che attiverebbe automaticamente il processo di rilascio, o ancora meglio, un sistema che rilascerebbe una nuova versione del software in un momento tempo designato. Naturalmente, questo è difficile da ottenere perché è anche necessario automatizzare gran parte del processo di test, ma non è impossibile.

Abbracciare le migliori pratiche

In questa sezione descriverò un paio di pratiche consigliate che ho trovato convenienti, sia per rendere più agevole il processo di rilascio sia per adottare misure di sicurezza nel caso qualcosa vada storto.

Trova il giorno più adatto per effettuare il rilascio

Di solito rilascio le app su cui lavoro il giovedì, tra mezzogiorno e la chiusura dell'attività.

Se lavori dal lunedì al venerdì, non è una buona idea iniziare di venerdì. Se qualcosa si guasta dopo il rilascio, non avrai tempo per risolverlo fino a lunedì (a meno che tu non voglia lavorare durante il fine settimana). Ecco perché è più conveniente eseguire le versioni giovedì, perché venerdì hai a disposizione per monitorare la nuova versione dopo essere stata distribuita, risolvere eventuali problemi o eseguire un rollback.

Un'altra cosa importante da menzionare se gestisci un'app Web è conoscere il fuso orario in cui si trova la maggior parte dei tuoi utenti. Dovresti programmare il rilascio durante un periodo di traffico limitato per ridurre al minimo il potenziale danno se qualcosa non funziona. A volte, questo può essere complicato quando la tua base di utenti è sparsa in tutto il mondo, ma comunque dovresti fare qualche ricerca e decidere il momento migliore.

Eseguire il backup del database prima di una nuova versione

Se non hai pianificato backup periodici del tuo DB, ti consiglio vivamente di aggiungere un passaggio nel processo di rilascio per eseguire un backup prima di iniziare il rilascio.

Lanci a tappe

Ti sei mai chiesto perché, quando un editore annuncia di aver lanciato una nuova funzionalità, ci vogliono giorni o addirittura settimane perché quella funzione sia disponibile sul tuo telefono? Questo perché molte aziende utilizzano implementazioni graduali.

Facebook lo fa da molto tempo. Testa una nuova funzionalità su cinque o 10 percento dei suoi utenti, aumentandola gradualmente fino a raggiungere il 100 percento della base di utenti. Durante la fase di implementazione graduale, dovrai esaminare da vicino il feedback degli utenti e i rapporti sugli arresti anomali. Con queste informazioni, puoi quindi posticipare il rilascio o correggere gli errori prima che influiscano su tutti gli utenti.

C'è un bel strumento sulla Console per gli sviluppatori di Android che implementa implementazioni graduali per le tue app Android.

Integrazione continua

L'integrazione continua è una pratica che vale la pena abbracciare per molte ragioni. In primo luogo, ti consente di rilevare gli errori in anticipo, aumentando il tasso di rilasci di successo. In secondo luogo, è il primo passo logico prima di implementare la Continuous Delivery e la completa automazione come descritto in precedenza.

Martin Fowler è un grande sostenitore dell'integrazione continua. Descrive un'enorme quantità di vantaggi che possono essere aggiunti al processo di rilascio quando si utilizza questa pratica. Questo è un argomento ampio e ci sono molti libri e post di blog a riguardo, e lo cito qui perché credo che ti darà molta più fiducia nelle tue operazioni. Tra i numerosi vantaggi dell'utilizzo della CI, troverai: rischio ridotto, maggiore visibilità per sapere cosa funziona e cosa no, rilevamento precoce dei bug, maggiore frequenza delle implementazioni e molti altri.

Il punto di partenza per l'implementazione della CI è configurare un "server di integrazione continua"; alcuni strumenti interessanti da provare sono: CruiseControl, Bamboo, Jenkins e Travis.

Exitlude: Andrà tutto bene

Aggressivamente, difendiamo tutti il ​​ruolo che svolgiamo Purtroppo, i tempi arrivano per mandarti sulla tua strada Abbiamo visto tutto, falò di fiducia, inondazioni improvvise di dolore Non importa, non ti preoccupare, sarà tutto funziona

Exitlude, Gli assassini

Per concludere, direi che è molto importante avere un processo di rilascio ben definito per la tua app, indipendentemente dalla sua complessità, base di utenti o dalle dimensioni della tua organizzazione.

In caso contrario, ti suggerisco di iniziare a pensare ad alcuni passaggi di base, utilizzare questa guida e altre simili e fare un brainstorming con il tuo team per elaborare una prima bozza. Provalo alla prossima versione, quindi itera. Alla fine, finirai per costruire il tuo processo di rilascio.

Dopodiché, inizia a pensare a come automatizzare parti del processo . Pensa alle aree che possono essere migliorate. Esplora i modi per ridurre il tempo di rilascio incorporando piccole ottimizzazioni. L'automazione dovrebbe essere il tuo obiettivo finale; tuttavia, non pianificarlo dall'inizio, o fallirai tentando un salto così grande. Come per ogni processo, è meglio migliorarlo gradualmente.

Hai altri trucchi o linee guida che usi per lanciare nuove versioni della tua app? Se è così, fammi sapere. Non vengo dal mondo DevOps, sono solo uno sviluppatore che sembra essere abbastanza organizzato e strutturato, ma rispetto a molti veterani sono ancora un principiante in questo senso, quindi sentiti libero di commentare o contattami se hai qualcosa da aggiungere.