Continous Integration con GitLab e Symfony

GitLab è un software per la gestione del codice, un prodotto completo disponibile anche gratuitamente.

In questo articolo vedremo come configurare un progetto per l’esecuzione automatica di test e aggiornamento del codice in ambienti di produzione.

È sicuramente necessaria avere una conoscenza operativa di git, bash, raccomandato il sistema operativo Linux in versione server e infine saper usare GitLab, dando per scontato che sia già installato e operativo.

 A cosa serve il CI?

La procedura di integrazione continua in un progetto semplifica e automatizza di molto le noiose procedure da effettuare al termine di una sessione di coding. 

Ad esempio, ci si immagini di aver terminato una nuova sezione di un sito e di doverlo già caricare nell’ambiente di produzione del cliente. Solitamente, nei casi più semplici, basterebbe collegarsi in FTP e aggiornare i file modificati.
Nei casi un pochino più complessi, quando si ha a disposizione un server dedicato e di conseguenza SSH (e SFTP), la procedura è più professionale. Infatti possiamo aggiornare il codice demandando il lavoro a Git. 
Nei casi ancora più complessi ed evoluti, si potrebbe pensare di effettuare alcune ulteriori opere di manutenzione per la messa online del progetto, si pensi ad esempio all’utilizzo di un framework e in questo caso parleremo di Symfony, svuotamento cache, aggiornamento schema del database e installazione dei pacchetti con Composer.

E infine, se si vuole essere sicuri di non danneggiare l’ambiente di produzione, avendo a disposizione un solo server, la soluzione di apprezzabile dignità sarebbe quella di effettuare operazioni dedicate al progetto quali la copia di backup dei file in produzione, far puntare ad Apache o Nginx a questa cartella e infine lavorare alle operazioni di aggiornamento nella zona non visibile al pubblico. Se tutto è a posto, allora è possibile cambiare i puntamenti.

 Elementi necessari:

• GitLab (anche in versione gratuita)
• Un progetto di Symfony
• Un server di produzione (e di staging, ma può essere lo stesso)
• Un utente SSH con relativa chiave privata

 1 – Configurazione del file:

Nella root del progetto è necessario creare un documento che avrà come contenuto le istruzioni per l’integrazione continua.

Crea .gitlab-ci.yml e inserisci il seguente codice:

Contiene:

1. image: useremo un pacchetto utile per la connessione SSH
2. before_script: inizializzeremo la connessione SSH verso il server in produzione e staging
3. stages: avremo a disposizione due ambienti staging e production
4. staging: configuriamo i due ambienti
   1. staging ▸ script (branch staging)
      Lo script si connetterà via SSH al server staging e effettuerà il backup. Poi cambierà il puntamento semplicemente spostando il collegamento verso la cartella di backup.
      Nella cartella operativa invece aggiornerà il codice con Git, eliminando tutte le eventuali modifiche non registrate e spostandosi nel commit specificato (inserito automaticamente come variabile).
      Infine effettuerà le operazioni dedicate per Symfony, ovvero aggiornamento dei pacchetti con Composer, aggiornerà lo schema dei dati (nel caso in esempio è stato utilizzato il vecchio sistema, in realtà si potrebbe fare di meglio con le migrazioni).
      Se tutto è andato bene senza errori, allora è possibile cambiare nuovamente il puntamento verso la cartella operativa. 
      Il backup verrà eliminata la prossima volta e rimpiazzata dalla copia della cartella operativa.
   2. production ▸ script (branch master)
      Le operazioni sono essenzialmente le stesse, impostate sul server in produzione. In casi specifici potrebbe essere necessario operare su processi particolari nella macchina, quali ad esempio il servizio cache del web server.

 2 – Configurazione del progetto su GitLab:

Aprire il progetto, Impostazioni ▸ CI/CD ▸ Variables creare 4 variabili

• SSH_HOST per indicare quale server connettere in SSH
• SSH_KNOWN_HOSTS per poter verificare automaticamente la connessione SSH, è possibile generarlo da un computer sicuro con ssh-keyscan [HOST]
• SSH_USER l’utente SSH
• SSH_PRIVATE_KEY la chiave privata dell’utente SSH

Proteggere le variabili delicate e abilitare la lettura di tali dati da parte di alcuni branch, ovvero master e staging in Impostazioni ▸ Repository ▸ Protected Branches

 3 – Configurazione server web:

Nel mio caso, utilizzo apache2 con puntamento ad un file simbolico. Quest’ultimo poi si occupa di reindirizzare verso la cartella operativa o quella di backup.

 4 – Risultati finali:

Ogni commit (o merge) sui branch che abbiamo indicato nel file di configurazione, avranno il loro processo dedicato nella pagina CI/CD ▸ Pipeline

Gli ambienti con possibilità di aprire la loro pagina web e…

La possibilità di ripristinare rapidamente un vecchio commit o merge con un tasto.
Attenzione perché manca il supporto per lo schema dei dati: non verrà alterato ma potrebbe essere implementato tra i vari comandi che vengono eseguiti.

Ecco il risultato finale nell’intestazione del progetto: 

E tra tutti gli altri progetti, dove hanno una immediata indicazione del supporto CI di GitLab.

.