...
Scarico da cld-config il file /var/puppet/KeyRepoEpoxyTesting e copiarlo ad esempio in ~/Workdir
| Code Block |
|---|
Workflows
Modifica
...
semplice, non pericolosa, da riportare in produzione
Esempi in questa categoria:
- cambio del valore di un parametro in params.pp
- Aggiunta di un nodo per cui non si applica l'overcommitment
Chi fa la modifica committa in testing dalla sua postazione di lavoro.
Per prima cosa si verifica che il proprio repo locale sia aggiornatoMi accerto che la copia locale del mio repo (branch testing) sia aggiornata:
| Code Block |
|---|
$ 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. |
...
| Code Block |
|---|
git crypt unlock ~/Workdir/KeyRepoEpoxyTesting |
A questo punto faccio le modifiche si fa la modifica sul branch testing, che poi committo si committa e pushosi pusha:
| Code Block |
|---|
# fai modifiche git add <files modificati> git commit -m "Messaggio" <files modificati> git push |
Workflows
Modifica semplice, non pericolosa, da riportare in produzione
Esempi: cambio di un valore di un parametro in params.pp e/o altre modifiche minime/non pericolose
...
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
- Va
Si va in: https://github.com/CloudPadovana/puppet_epoxy → Pull requests e poi "New pull requests"
Seleziona Si seleziona in alto "main" come base e "testing" come compare e
clicco 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
Sviluppo e testing di una nuova funzionalita'/bug fix
...
Si crea un nuovo branch
...
ad hoc a partire da
...
testing. Come nome del branch scegliere un nome che sia significativo con la modifica che si sta facendo:
| Code Block |
|---|
$ 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.
$ git checkout -b <nome-del-branch> |
Fare le modifiche del caso e poi committare e pushare:
| Code Block |
|---|
git add .
git commit -m "Your detailed description of your changes."
git push origin <nome-del-branch> |
Se serve usare la cloud di test per testare questi sviluppi
...
per prima cosa si avvertono tutti (chiedendo che nessuno committi in testing se non strettamente necessario)
...
Poi si mette in /var/puppet/puppet_epoxy_env_test
...
di cld-config quanto sta ne branch di sviluppo
Occhio che se qualcuno
...
nel frattempo committa in testing, il contenuto di /var/puppet/puppet_epoxy_env_test sara' automaticamente sincronizzato con il branch testing
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):
Si apre una PR da questi branch di devel creato ad hoc a testing:
Si va in: https://github.com/CloudPadovana/puppet_epoxy → Pull requests e poi "New pull requests"
Si seleziona in alto "testing" come base e il branch di devel come compare e si clicca su "Create pull request"
Questo triggera il deployment della modifica sulla cloud di test
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
Sincronizzazione tra main e testing
...
In generale quello che e' su testing e' roba gia' testata (almeno singolarmente) o una modifica semplice e che voglio che finisca in produzione.
Quindi prima o poi deve finire anche su main (dopo la fase di testing delle modifiche fatte sulla cloud di test).
...