Page History

...

• Esiste un git repo unico sia per la parte controller che per la parte compute con 2 branch principali:
  • Il branch 'main' viene usato  nella cloud di produzione (environment  'production' di puppet)
  • Il branch 'testing' viene usato nella cloud di test (environment 'testing' di puppetdove vanno riportate tutte e sole le cose gia' testate che devono andare in produzione 
• Oltre a questi 2 branch principali, esistono dei branch creati ad hoc che vengono usati per lo sviluppo di nuove funzionalita'/bug fix (vedi sotto)
  • Quando il codice relativo e' stato testato e si ritiene che sia pronto per andare in produzione, si riporta tale codice in testing.

• Il codice puppet che viene usato sta in cld-config. ma non si deve MAI modificare i sorgenti puppet direttamente su cld-config
  • Per la cloud di produzione sta in cld-config nella directory /var/puppet/puppet_epoxy
    • Questo codice viene automaticamente sincronizzato dal branch main
    • Non si deve  MAI modificare i sorgenti puppet della directory /var/puppet/puppet_epoxy di cld-config
  • Per la cloud di test sta in cld-config nella directory /var/puppet/puppet_epoxy_env_test
    
    • Un webhook fa un "git checkout"  da testing ogni volta che c'e' un commit su questo branch
    • Quindi solitamente il codice che sta in questa directory corrisponde a quanto sta nel branch testing (salvo quando si devono testare nuovi sviluppi: v. sotto)

• Modifiche al codice vanno implementate:
  • Per cloud di test  committando (lavorando sulla propria postazione di lavoro) committando sul branch testing. Queste vengono apoi utomaticamente "scaricate" in cld-config
  • Per cloud di produzione (quindi branch main) solo come pull request lavorando sulla propria postazione di lavoro. Una volta che sono approvate (e quindi mergiate nel branch main) queste vengono automaticamente "scaricate" in cld-config
• Prima si modifica sul branch testing e poi (dopo una fase di testing) la modifica deve finire anche in main
  • Modifiche solo in main non devono essere fatte

...

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

Modifica del codice puppet per la cloud di produzione

Se devo riportare le  modifiche da testing a main (quindi per metterle in produzione): 

...

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

• Chi fa la modifica committa in testing dalla sua postazione di lavoro
• Verifica che a seguito della modifica non viene rotto nulla nella cloud di test (dove la modifica viene automaticamente propagata)
• Lo sviluppatore apre una PR per mettere la modifica in produzione

  • Va in:  https://github.com/CloudPadovana/puppet_epoxy → Pull requests e poi "New pull requests"

...

• • 
    

  • Seleziona in alto "main" come base e "testing" come compare e clicco su "Create pull request"

...

• Quando la PR

...

• viene approvata, la modifica viene automaticamente installata in produzione

Sviluppo di una nuova funzionalita'/bug fix

• Creo un nuovo branch (a partire da testing)
• Faccio le modifiche su questo branch
• Se mi serve la cloud di test per testare questi sviluppi
  • Avverto tutti (chiedendo che nessuno committi in testing)
  • Metto in /var/puppet/puppet_epoxy_env_test quello del branch)
    • Occhio che se qualcuno committa in testing quello che sta nel mio repo non viene 

Sincronizzazione tra main e testing

...