Usiamo un meccanismo di CI/CD per cui:
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 |
mkdir ~/Workdir cd ~/Workdir git clone https://github.com/CloudPadovana/puppet_epoxy.git |
Scarico da cld-config il file /var/puppet/KeyRepoEpoxyTesting e copiarlo ad esempio in ~/Workdir
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
Si va in: https://github.com/CloudPadovana/puppet_epoxy → Pull requests e poi "New pull requests"
Si seleziona in alto "main" come base e "testing" come compare e si clicca su "Create pull request"
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
Dopo che la modifica e' stata fatta (su un branch ad-hoc di devel) e testata (v. punto precedente):
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',
|