DevOps è principalmente cultura aziendale e di team, DevOps è una nuova visione in cui alcune di quelle che sono le barriere tra mondo dello sviluppo e mondo operations vengono abbattute al fine di generare sinergie inimmaginabili prima. Vorrei raccontare due esperienze vissute in due scenari molto diversi tra loro, due scenari in cui DevOps è stato da un lato il traguardo di un processo evolutivo dal monolite ingestibile a SOA/Microservices e dell'altro invece DevOps è stato il motivo scatenante finalizzato a superare tutta una serie di ostacoli amministrativi e burocratici che rendevano impossibile il deploy in produzione.

1. 1
Mauro Servienti
mauro.servienti@gmail.com
@mauroservienti
DevOps e scelte
architetturali
tre scenari reali

2. Sponsors & Organizers
getlatestversion.it

3. Architettura
Una ed una sola?

4. 4+1 architectural view model

5. 4+1 architectural view model

6. 4+1 architectural view model

7. 4+1 architectural view model

8. DevOps
Everybody,
all together

9. Take 1: Development View

10. Calato nel day by day
Operativamente?

12. Tempo

13. Tempo

14. Tempo
Branch

15. Tempo
Branch PR

16. Tempo
Branch PR Unit Test
Acceptance Test

17. Branch PR Unit Test
Acceptance Test
Tempo

18. Tempo
Branch PR Unit Test
Acceptance Test

19. Tempo
Branch PR Unit Test
Acceptance Test

20. Tempo
Branch PR Unit Test
Acceptance Test

21. La rilascia in
produzione

22. Facile direte voi…
Ci fermiamo a
Nuget…

23. Non proprio…
Dobbiamo ridurre
all’osso la
superficie d’errore

24. Architettura
Granularità dei
package

25. E per chi dipende
da noi?

26. Take 2: Process View

27. «Il monolite»

28. Il monolite
Il deploy deve
deployare tutto

29. Il monolite
L’accoppiamento è
fortissimo

30. Il monolite
accoppiamento
impedisce la
conoscenza

31. Il monolite
Obbliga a introdurre
strutture ad hoc per il
supporto

32. Il monolite
Strutture ad hoc
generano
disinteresse

33. Il monolite
Il disinteresse
produce non-qualità

34. Il monolite
La non-qualità
genera un circolo
vizioso

35. Il monolite
Nessuno vuole avere
a che fare con il
monolite

36. Prendi chi produce e
rendilo reperibile

37. Innescando la
necessità di essere
responsabili

38. controllo granulare
che impatto hanno le
modifiche

39. controllo granulare
dove-come-quando
vengono rilasciate

40. struttura granulare
Controllo granulare
implica una struttura
adeguata

41. struttura granulare
Deve essere
verticale
Non orizzontale

42. A questo punto ci manca
Controllo e
Semplicità

43. Controllo
Octopus

44. Semplicità
PowerShell DSC

45. Take 3: Physical View

46. All’estremo opposto
TFS
Release Manager

47. Il monolite
È il processo di
deploy

48. Il deploy è anche
Ricco di vincoli legali

49. Il tool e i vincoli
Rilasci accorpati il
più possibile

50. Lo stimolo
Superare la barriera
al rilascio

51. Come un gambero
Rendendo in primis
granulare il rilascio

52. Come un gambero
Semplificando il
rilascio in ambienti
«complessi»

53. Semplicità
PowerShell DSC

54. Se finisce in semplicità
Perché iniziarlo
complesso?

55. Le famose fettine verticali
componenti che
cooperano per il
risultato

56. Summary

57. Architettura
•Granularità
•Fette verticali
•Bassissimo accoppiamento
•Attenzione all’accoppiamento temporale

58. DevOps
Service Oriented
Architecture

59. Persone
•Fiducia
•Responsabilità

60. DevOps
Everybody,
all together

61. Everybody,
all together,
from the early on

62. Mauro Servienti
Solution Architect, Particular Software
Grazie