Omar Rossini ha presentato tutti gli aspetti principali del lavoro di Configuration Manager: dall'analisi della metodologia DevOps in contesto Agile, alle tecniche di automazione dei rilasci e le best practice del CM.

1. Configuration
Management
Il ruolo del Configuration Manager nel moderno ciclo di
vita del software

2. Presentazioni
Sono Omar Rossini e lavoro nell’IT da
circa 10 anni. Ho iniziato come
Tester/sviluppatore per poi diventare
un Configuration Manager, ruolo che
ricopro da circa 8 anni. Ho lavorato
come consulente per vari clienti tra cui
Siemens, Nokia, Fastweb, H3G/Wind,
ING Direct ed attualmente, da quando
sono approdato in ThinkOpen, gestisco
uno dei team interni di Configuration
Management di Reply.
Spero in questo breve workshop di darvi delle informazioni utili e delle basi su cui
ragionare per continuare a crescere come professionisti dell’IT.
E ADESSO INIZIAMO!

3. Copyright 2011 - 2018, ThinkOpen S.r.l.
DevOps - Develop … Operations
La parola stessa già racchiude il significato di questo termine. Avvicinare e
legare lo sviluppo e l’operation in modo da aprire un dialogo collaborativo ed
integrare le conoscenze dei vari dipartimenti con lo scopo di aiutare
un'organizzazione a sviluppare in modo più rapido ed efficiente prodotti e
servizi software.

4. Copyright 2011 - 2018, ThinkOpen S.r.l.
DevOps
Principi Base
Su quali concetti si basa
questo modo di lavorare?
1. Continuous Integration
2. Continuous Testing
3. Configuration Management
4. Continuous Provisioning
5. Continuous Deployment

5. Copyright 2011 - 2018, ThinkOpen S.r.l.
“Habitat” del Configuration Manager
Gestione ticket/issue Tracker
Repository e Tool di gestione degli stessi
Tool di Build e Build Automation
Gestione Artefatti
Tool di verifica del codice sorgente e Hooks

6. Copyright 2011 - 2018, ThinkOpen S.r.l.
GIT FLOW

7. Copyright 2011 - 2018, ThinkOpen S.r.l.
Builds
Nomenclature e differenze
Ci sono molti tipi di build chiamati con diversi nomi di seguito alcuni
esempi:
● nightly
● weekly
● snapshot
● stable
Cosa significano?
Vediamoli uno ad uno ed andiamo a collocarli sullo schema della slide
precedente per dargli anche un contesto pratico oltre che un significato
che è già comunque piuttosto esplicito nel nome.

8. Copyright 2011 - 2018, ThinkOpen S.r.l.
Best Practices
In ogni contesto esistono cose che è meglio fare ed altre che è meglio evitare.
Nel nostro caso più l’automazione è spinta e più abbiamo bisogno di regole
ferree per far sì che tutto funzioni. E’ inutile negare che spesso avere dei paletti
può sembrare un impedimento inutile però dobbiamo tenere sempre ben
presente una cosa:
Ad ogni regola corrisponde un’eccezione ma ad ogni eccezione corrisponde
un aumento del rischio che qualcosa vada storto a volte anche con dei costi
molto elevati.

9. Copyright 2011 - 2018, ThinkOpen S.r.l.
COSA E’ MEGLIO FARE
● Il Repository è la “Source of Truth” del software e deve quindi
essere sempre al pari o avanti rispetto agli ambienti.
● La build avviene sul codice del branch remoto ed il
pacchetto/artefatto viene salvato su un artifact repository.
● I pacchetti da installare sugli ambienti vengono sempre
prelevati da un’unica fonte predisposta dal configuration
manager su cui convergono tutte le build.
● I file di configurazione dato che sono “environement oriented”
vanno versionati come template.
● I branch di sviluppo devono essere sempre aggiornati dal loro
branch padre.
● Fare spesso delle commit per ogni piccola modifica inserendo
SEMPRE un commento “parlante”.
● Fare le Push solo quando si è assolutamente convinti e sicuri
del contenuto che stiamo per portare sul repo remoto.
● Utilizzare i Tag per segnare milestone/traguardi, build e rilasci.
● Dare ai branch dei nomi che esplicitano univocamente il loro
scopo.

10. Copyright 2011 - 2018, ThinkOpen S.r.l.
COSA E’ MEGLIO NON FARE
● Aspettare per integrare le proprie modifiche.
● Fare modifiche a mano sugli ambienti.
● Effettuare build e condividere artefatti su canali diversi da quello
ufficiale condiviso.
● Fare una push sul branch remoto senza aver fatto prima una
pull.
● Fare commit o merge senza commento o con commenti poco
chiari.
● Usare fogli excel o mail invece dei tool.
● Gestire i conflitti in maniera superficiale.
● In caso di dubbi, non condividere le soluzioni attuate con i
colleghi.

11. Copyright 2011 - 2018, ThinkOpen S.r.l.
Gra a T t
pe
l’at z o

12. Copyright 2011 - 2018, ThinkOpen S.r.l.
Contatti
Sede operativa - Italia
Strada 1 Palazzo F2 - Piano 5
Centro Direzionale Milanofiori,
20090 Assago Milanofiori (MI)
Tel: 02 36633490
Sede legale - Italia
Via Francesco Sampietro, 8
27026 Garlasco (PV)
Tel: 0382 1996994
Sede operativa estera - Spagna
Carrer de Pere IV, 74, tienda 1-2
08005 Barcellona (BC)
+34 653 311 121
www.thinkopen.it