Overview


Usiamo un meccanismo di CI/CD per cui:











Setup iniziale dell'ambiente sulla propria postazione di lavoro


Installazione git-crypt


Va installato git-crypt

Per i sistemi RHEL compliant esiste in EPEL (quindi 'yum install git-crypt')

Se non c'e' il pacchetto per la propria distribuzione, si puo' installare da sorgente (dipendenze: gcc-c++ e openssl-devel):



git clone https://github.com/AGWA/git-crypt.git
make
make install PREFIX=/usr/local



Download del repo git



mkdir ~/Workdir
cd ~/Workdir
git clone https://github.com/CloudPadovana/puppet_epoxy.git




Scaricare la chiave per il crypting dei file params.pp


Scarico da cld-config il file /var/puppet/KeyRepoEpoxyTesting e copiarlo ad esempio in ~/Workdir









Workflows


Modifica semplice, non pericolosa, da riportare in produzione


Esempi in questa categoria:


Chi fa la modifica committa in testing dalla sua postazione di lavoro.

Per prima cosa si verifica che il proprio repo locale sia aggiornato:


$ cd ~/Workdir/puppet_epoxy/


$ git checkout testing
Switched to branch 'testing'
Your branch is up to date with 'origin/testing'.

$ git pull
Already up to date.


Se serve modificare anche un file params.pp, farne prima il decrypt (decrypt che avviene solo locamente: sul repo i file restano cryptati):


git crypt unlock ~/Workdir/KeyRepoEpoxyTesting



A questo punto si  fa la modifica sul branch testing, che poi si committa e si pusha:


 # fai modifiche 
git add <files modificati> 
git commit -m "Messaggio" <files modificati> 
git push


Se la cloud di test era usata per test di una nuova funzionalita' (vedi sotto) si avverte il relativo utente perche' si resetteranno le sue modifiche in /var/puppet/puppet_epoxy_env_test di cld-config


Si verifica che a seguito della modifica non viene rotto nulla nella cloud di test (dove la modifica viene automaticamente propagata)


 Si apre una PR per mettere la modifica in produzione


Occhio che la PR conterra' anche eventuali altre modifiche fatte in testing da altri utenti


Quando la PR viene approvata, la modifica viene automaticamente installata in produzione




Sviluppo e testing di una nuova funzionalita'/bug fix




Messa in produzione di una nuova funzionalita'/bug fixing


Dopo che la modifica e' stata fatta (su un branch ad-hoc di devel) e testata (v. punto precedente):









Sincronizzazione tra main e testing


In generale quello che e' su testing prima o poi deve finire anche su main (dopo la fase di testing delle modifiche fatte sulla cloud di test).

La "sincronizzazione tra main e testing va gestita "a mano" (v. sopra)


Per vedere i file che differiscono tra main e testing:


$ git diff --stat main..testing 
 .gitattributes                              | 3 +++
 README.md                                   | 1 -
 compute_epoxy/manifests/neutron.pp          | 1 +
 compute_epoxy/manifests/nova.pp             | 1 +
 controller_epoxy/manifests/configure_ec2.pp | 1 +
 5 files changed, 6 insertions(+), 1 deletion(-)






Per vedere le differenze in un file:



$ git diff main..testing controller_epoxy/manifests/configure_ec2.pp
diff --git a/controller_epoxy/manifests/configure_ec2.pp b/controller_epoxy/manifests/configure_ec2.pp
index abcbb1a..5bc9adf 100644
--- a/controller_epoxy/manifests/configure_ec2.pp
+++ b/controller_epoxy/manifests/configure_ec2.pp
@@ -8,6 +8,7 @@ class controller_epoxy::configure_ec2 inherits controller_epoxy::params {
 
 ##
 # FF aggiungo questa riga di test
+# e anche un'altra
 ##
 
 file { ['/var/lib/ec2-api',