Versioning schemes and branching models for Continuous Delivery - Continuous Delivery meetup - Alkmaar, 18-05-2016
•Télécharger en tant que PPTX, PDF•
5 j'aime•3,724 vues
There are many different versioning schemes and branching models. Although there’s no golden standard, some of them suit Continuous Delivery more than others. Both branching and versioning are fundamental to the software development life cycle and I discussed different methods that communities developed over years along with their advantages and disadvantages.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Versioning schemes and branching models for Continuous Delivery - Continuous Delivery meetup - Alkmaar, 18-05-2016
Similaire à Versioning schemes and branching models for Continuous Delivery - Continuous Delivery meetup - Alkmaar, 18-05-2016 (20)
Dernier
Dernier (20)
Versioning schemes and branching models for Continuous Delivery - Continuous Delivery meetup - Alkmaar, 18-05-2016
- 1. Versioning schemes, branching models Support your Continuous Delivery process Continuous Delivery meetup, 18-05-2016 Triple, Alkmaar Pavel Chunyayev
- 2. @PavelChunyayev Amsterdam Levi9 HQ Amsterdam – 2005 25 people Novi Sad Serbia Novi Sad – 2005 320+ people Zrenjanin Serbia Zrenjanin– 2014 30+ people Iasi Romania Iasi – 2007 80+ people Kiev Ukraine Kiev – 2008 130+ people
- 4. @PavelChunyayev Customer satisfaction 2015 • 4th year great results in Outsourcing Performance study • 2015: 100% customer recommendation score Excellent trust score
- 5. @PavelChunyayev About me • 12 years of IT experience • Lived and worked in Ukraine and Estonia • Moved a year and half ago to the Netherlands • Love cycling • Learn Dutch • Alpe d’HuZes - http://deelnemers.opgevenisgeenoptie.nl/levi9
- 7. @PavelChunyayev Continuous Delivery Incept • Business idea • Is needed immediately • Should be validated Plan • Refine • Estimate • Prioritize Develop • Put into sprint • Develop in a branch • Conduct a code review • Merge into master Build • Trigger pipeline • Build • Unit testing • Integration testing • Static code analysis Test • Contract testing • E2E testing • Security testing • Resilience testing Release • Zero-downtime • Canary testing • Rolling deployment • Blue / green deployment Operate • Monitoring • Validation of the idea • Money generation • Disposal
- 9. @PavelChunyayev Keep the product releasable Build quality in
- 10. @PavelChunyayev Build • Test • Release
- 11. @PavelChunyayev Continuous Delivery Incept • Business idea • Is needed immediately • Should be validated Plan • Refine • Estimate • Prioritize Develop • Put into sprint • Develop in a branch • Conduct a code review • Merge into master Build • Trigger pipeline • Build • Unit testing • Integration testing • Static code analysis Test • Contract testing • E2E testing • Security testing • Resilience testing Release • Zero-downtime • Canary testing • Rolling deployment • Blue / green deployment Operate • Monitoring • Validation of the idea • Money generation • Disposal
- 12. @PavelChunyayev
- 13. @PavelChunyayev
- 14. @PavelChunyayev
- 15. @PavelChunyayev
- 16. @PavelChunyayev
- 18. @PavelChunyayev Versioning models • Versioning SaaS vs installed applications • Releases, bugfixes and hotfixes • Numeric • Date based • Semantic versioning • Marketing versions
- 19. @PavelChunyayev Numeric • Major.Minor • Major.Minor.Patch • Major.Minor.Patch.Build • Major.Minor.Build • Major.Minor.Build.Revision • Major.Minor.Date • 4.11, 5.2 • 5.2.1, 9.3.2 • 1.6.8.529 • 1.6.529 • 1.6.529.e91ba3 • 1.6.150518
- 20. @PavelChunyayev Major.Minor • -SNAPSHOT, -M1, -RC1, -RELEASE (.RELEASE) • 1.0-SNAPSHOT • 5.6-RC1 • 2.5.0-M2 • 5.2.1.RELEASE
- 21. @PavelChunyayev How to change version? • Software never reaching 1.0 • Rapidly increasing version
- 22. @PavelChunyayev Date based • Major.Minor.Date or just Date • 2.5.201505181 • 0.2.2015051801 • 1.7.20150518001 • 1.0.201505181936 • 3.1.20150518193956 • 20150518194513 • 2015.05.18-19.46.15
- 23. @PavelChunyayev Semantic versioning • Major.minor.patch-prerelease+metadata • 0.1.4-b45+d2e760 • 0.1.5-46 • 0.2.0-150518 • 0.2.1-prerelease+b538 • 1.0.0-alpha • 1.3.9-beta • 2.0.0
- 24. @PavelChunyayev Semantic versioning • Semver and continuous delivery • Assigning a version before release or after? • Enforcing the sequence of pull requests? • Not really needed for SaaS • Build number is an abuse of semantic versioning • Backwards compartible change or not? • Integrated application • Collection of applications
- 25. @PavelChunyayev Marketing version • Whatever product management or marketing decide to call it • 2016 Early • 2016.5 • Ultra, Turbo, Extra, VIP, Premium, Free • How often to release and how often to increase the version number?
- 26. @PavelChunyayev How to generate and save version number • In the source code • External • Date • Build number • Source control • Bump up the version • Before new feature or after new feature • Manually vs script while commiting (hooks)
- 27. @PavelChunyayev What to version? • Your product • Separate applications • Libraries, building blocks and tools • Public and private (internal versioning) • Public (and private) API • DB schemas • Infrastructure configuration
- 28. @PavelChunyayev Versioning things • Embedded (meta information) vs filename • Package the code and assign version to the packages • Dependency management • Latest • Ranges • Explicitly specified
- 29. @PavelChunyayev Version of the product in microservices world?
- 36. @PavelChunyayev Models • SaaS vs installed • Trunk-based • Feature driven • Release branches • Git flow • Open-source
- 42. @PavelChunyayev Branching things • Tagging • Fork vs branching • Pull requests (merge requests) • Run tests • Code review
- 43. @PavelChunyayev Continuous Delivery Incept • Business idea • Is needed immediately • Should be validated Plan • Refine • Estimate • Prioritize Develop • Put into sprint • Develop in a branch • Conduct a code review • Merge into master Build • Trigger pipeline • Build • Unit testing • Integration testing • Static code analysis Test • Contract testing • E2E testing • Security testing • Resilience testing Release • Zero-downtime • Canary testing • Rolling deployment • Blue / green deployment Operate • Monitoring • Validation of the idea • Money generation • Disposal Keep the product releasable Build quality in Version everything Branch out when needed
- 44. @PavelChunyayev Key takeaways • Focus on quality, speed will come • Quality has to be integral part of the process • Version each artifact uniquely • Select the branching model that supports your product • Integrate frequently Any questions? pavel@levi9.com
Notes de l'éditeur
- Ideas come from all the sources. Questions are welcome. Disagreement is welcome, but after the talk.
- .
- .
- .
- .
- Not every feature is needed. Shorter and shorter release cycles => Release more software in less time.
- Can’t churn out. No manual testing.
- .
- .
- .
- Reproducible and repeatable process (including testing). Potentially shippable product -> Keeping the product releasable
- .
- Testing criteria. Run over and over again.
- .
- No DTAP. Immutable (testing framework?) TTL Docker Framework to allow restart - select arbitrary test
- Windows 95 vs 98 Web 2.0 Star Wars, Terminator BMW
- FreeBSD
- F: 2 years to reach 1.0 6 years to reach 4.0 Latest is Firefox 54 Chrome 1.0 -> 4 in 1 year (Chrome 52)
- .
- .
- .
- Marketing vs CD
- Infrastructure becomes integrated with application
- .
- .
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versions – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- * Semantic or not semantic * API versioning - public or also internal? * Transition between versioning – testing different versions * Running several versions together
- You have to collaborate and therefore to work along with different people on the same repository
- Ideal for CD Tricky to convince developers to try Tricky with multiple developers Tricky with multiple teams Tricky for installed software Possible with correct tooling
- Golden standard for git Branches are used for convenience Works if branches are short lived Pull frequently from master Or before merge Or automatically Merge commits
- Supports installed software Easy for bug- and hot-fixes Tricky to manage Requires a role of release engineer or manager Tags can replace branches If you don’t support then long
- Good and easy for installed software Manual release process Cherry picking Can be trickier to use with CI/CD Merge commits
- Fork Add upstream as remote Code Squash commits Open Pull Request Merge Or get your PR rejected :)