Dall'idea al deploy un lungo viaggio che passa per git flow e semver
1 like254 views
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps 竪 principalmente una metodologia. Lo scopo 竪 rendere l'intera filiera il pi湛 fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi. Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog? Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
Dall'idea al deploy un lungo viaggio che passa per git flow e semver
- 1. #DOH17#DOH17
- 2. dall'idea al deploy un lungo viaggio che passa per GitFlow e SemVer Mauro Servienti @mauroservienti
- 4. @mauroservienti 4 DevOps 竪 prima di tutto una forma mentis. Gli strumenti sono una conseguenza
- 8. @mauroservienti #DOH17 Assiomi develop 竪 sempre rilasciabile come beta master 竪 sempre rilasciabile in produzione
- 9. @mauroservienti #DOH17 Supponiamo che Progetto vuoto: v0.0.0 Feature A: v0.1.0 Release: v0.1.0 Feature B e Feature C in parallelo: v? Il lavoro in parallelo complica il tener traccia Della versione Di cosa si 竪 rilasciato Della retro-compatibilit Con patch e hotfix si complica ancora di pi湛
- 11. @mauroservienti #DOH17 GitVersion Assegnare un numero di release 竪 un task da macchina non da umano senziente Cosa ci impedisce di guardare alla history e fare dei ragionamenti sullo stato attuale? generare un numero di versione sensato? develop -> unstable/beta master -> stable/release Disponibile come: Task di MSBuild Library Command line
- 12. Cosa fa GitVersion per noi
- 14. @mauroservienti #DOH17 gestione delle nuove feature feature/xyz Anche nome branch che volete voli Pull Request develop feature/super-segreta
- 16. @mauroservienti #DOH17 Pull Request e Review Nulla di diverso dal branch-per-feature tradizionale Un sistema basato sui concetti di GitHub introduce Pull Request Review Il nostro flusso diventa quindi: Branch -> Lavoro -> Push -> PR -> Review -> Merge
- 17. @mauroservienti #DOH17 PR -> review -> merge You cannot merge your own PR Importantissime in un processo attento alla qualit Le review sono la base della condivisione del sapere Siccome ci piace automatizzare: Introduzione delle build automatiche sulle PR Simili ad un gated check-in (per certi versi)
- 20. @mauroservienti #DOH17 gestione delle hotfix/patch nel passato develop master support/1.0 bug hotfix/1.0.1
- 21. @mauroservienti #DOH17 Perch辿 siamo cos狸 ossessionati dal numero di versione?
- 22. @mauroservienti #DOH17 Semantic Versioning vitale che una libreria comunichi le tipologie di cambiamento tra una versione e laltra
- 23. @mauroservienti #DOH17 SemVer: Major.Minor.Patch Il numero di versione ha una semantica ben precisa Major: la nuova versione contiene breaking changes Minor: nuove feature retro-compatibili Patch: bug fixing retro-compatibile Fondamentale per permettere a chi vi usa di capire cosa succeder Soprattutto se aggiorna senza ricompilare, come per le hotfix
- 24. @mauroservienti #DOH17 senza ricompilarebreaking changes Voi usate un mio assembly che contiene: void Foo() -> int Foo() enum Bar{ Coffee, Tea } -> enum Bar{ Coffee, Cappuccino, Tea } void FooBar() -> void FooBar( int arg: 10 )
- 25. @mauroservienti #DOH17 ApprovalTests (salvaci tu) Rompe la build se: ci sono breaking changes non rispettiamo SemVer OSS: //github.com/approvals/ApprovalTests.Net Tanto semplice quanto scrivere un test:
- 27. @mauroservienti #DOH17 Riassumendo Se non avete un processo basato su CI non avete un processo Continuous Integration 竪 la base della serenit GitFlow vi da la possibilit di gestire tutti gli scenari Automatizzate tutto lautomatizzabile Le persone sono fatte per pensare non per eseguire Semantic Versioning 竪 semplicemente buona educazione Spingetevi alla paranoia se ne avete bisogno ApprovalTests + ApiComparer
- 28. #DOH17#DOH17 Mauro Servienti Solution Architect @ Particular Software makers of NServiceBus mauro.servienti@particular.neti @mauroservienti //github.com/mauroservienti