...
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 verifico si verifica che il mio proprio repo locale sia aggiornato:
...
| 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 |
...
Se la cloud di test era usata per test di una nuova funzionalita' (vedi sotto) avverto si avverte il relativo utente perche' gli avro' "resettato" si resetteranno le sue modifiche in /var/puppet/puppet_epoxy_env_test di cld-config
Verifico Si verifica che a seguito della modifica non viene rotto nulla nella cloud di test (dove la modifica viene automaticamente propagata)
Apro Si apre una PR per mettere la modifica in produzione
Vado Si va in: https://github.com/CloudPadovana/puppet_epoxy → Pull requests e poi "New pull requests"
Seleziono 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 produzioneMessa
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).
...