Git strategy

Per la gestione GIT di entrambi i progetti si è scelto di utilizzare il modello GitFlow.

L’approccio GitFlow utilizza due rami principali per gestire il controllo di versione (versioning) del progetto. Il primo, master che conserva, come detto, tutte le release. Il secondo è il ramo develop, che è fondamentale per lo sviluppo delle prossime versione e serve come base per le future integrazioni che vedremo nei vari capitoli. È inoltre conveniente taggare tutti i commit (o merge) verso il master con un numero di versione progressiva.

Ogni nuova feature, quindi, dovrebbe avere il proprio branch, che deve essere presente anche su origin in modo da permettere agli altri sviluppatori di collaborare. I rami delle nuove funzionalità devono essere creati a partire da quello development e, quando abbiamo completato lo sviluppo della funzionalità, deve essere unito (merge) di nuovo in development. Non deve, MAI, essere unito direttamente a master.

Dopo aver completato lo sviluppo della nuova funzione, è ora di aggiornare il ramo development con le ultime modifiche. Al termine del merge è utile eliminare il branch di feature per mantenere git pulito e sapere quindi quali sono i branch ancora attivi e quali no.

Le operazioni di aggiornamento e build di master sono state automatizzate tramite la creazione sia in BE che in FE dello script shell ./build.sh. Lo script si occupa di mergiare development in master, di creare un git tag e di effettuare tutte le operazioni di build richieste dal singolo progetto.

Basterà poi aggiornare i server di produzione.

Per il frontend sarà sufficiente effettuare il pull di master

Per il backend saranno necessari i seguenti comandi in sequenza:

• git pull origin master
• ./run-make.sh migrate
• ./run-make.sh collectstatic

• sudo systemctl nginx reload

  ​