Dall'idea al deploy un lungo viaggio che passa per git flow e semver
•
1 gefällt mir•250 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.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Dall'idea al deploy un lungo viaggio che passa per git flow e semver
Ähnlich wie Dall'idea al deploy un lungo viaggio che passa per git flow e semver (20)
Mehr von Mauro Servienti
Mehr von Mauro Servienti (20)
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 l’altra
- 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 ricompilare…breaking 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 l’automatizzabile • 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