Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to CD Git Workflow & Tools
Similar to CD Git Workflow & Tools (20)
Recently uploaded
Recently uploaded (20)
CD Git Workflow & Tools
- 1. Git & Continuous Deployment
- 2. Continuous Deployment • The idea of pushing features as soon as it is “ready” – Potential of multiple deploys each day – Release features to customers faster – Reduces the number of features in a deploy • Problems in smaller deploys generally cause smaller problems – Requires better tools and architecture
- 3. A Proposed Workflow Ready to deploy code
- 4. A Proposed Workflow Ready to deploy code Listens for changes
- 5. A Proposed Workflow Ready to deploy code Code Change Triggers Build Listens for changes
- 6. A Proposed Workflow Ready to deploy code Code Change Triggers Build Listens for changes Successful build triggers deploy script
- 7. We Already Have These Code Change Triggers Build Listens for changes Successful build triggers deploy script
- 8. Code Isn’t Always Ready to Deploy SVN requires tradeoffs to work with CD 1. Use SVN branching and merging…you’ll pay in merge hell Ready to deploy code 2. Only develop on trunk, but only commit when your code is production ready . Not reasonable!
- 9. Code Isn’t Always Ready to Deploy SVN requires tradeoffs to work with CD 1. Use SVN branching and merging…you’ll pay in merge hell Ready to deploy code 2. Only develop on trunk, but only commit when your code is production ready . Not reasonable! Git ties in perfectly for CD • Excels at branching and merging However… 1. 2nd Class Citizen on Windows 2. You have to learn how to use it…and you’ll probably screw something up at least once. 3. No decent tools to work with many repos in 1 project...at least not on windows
- 10. A Git Development Model Master Test Dev 1. A repo has a branch for each environment – i.e. cre_data_tier would have 1 repo with 3 branches 2. The repo and branches are cloned onto your local machine – every clone has a complete copy of the repo 3. Developers would only branch from and merge into Dev
- 11. Adding a New Feature Master Test Dev new-feature 1. Developer branches off Dev and commits to that branch.
- 12. But Wait! There’s a Production Bug! Master Test Dev hot-fix new-feature 1. Developer goes back to Dev and makes another branch.
- 13. But Wait! There’s a Production Bug! Master Test Dev hot-fix new-feature 1. The fix is merged into Dev. 2. Assuming it is ok on Dev, The test admin merges the fix into Test. 3. Assuming it is ok on Test, the production admin merges into Master. 1. If there are a lot of features waiting to be released to Test or Master the admin would “cherry-pick” the commit they want.
- 14. Disaster Averted…back to work Master Test Dev hot-fix new-feature • The developer can pickup where they left off with the new-feature branch • Merge the finished feature into Dev • It propagates down to Master No incomplete code goes into the deployment lines
- 15. A Proposed Workflow Ready to deploy code Code Change Triggers Build Listens for changes Successful build triggers deploy script
- 16. Why? • Why would we want to do continuous deployment, or why use Git? – Why? • Why? – Why? » Why?
- 17. Tools Needed • A script to handle a multi-repo project – One branch command branches all repos, etc. • An automated deploy script • A way to tie commits to features and where they are in the deployment process (Ready for release, in Testing, etc) – If the admin needs to cherry pick a task he needs to know what commit goes with it. – If the admin is going to deploy whatever is ready, he needs to know what is ready. • A central Git Repo – We could use a 3rd party(GitHub, etc) or deploy our own. • For continuous production deploys, we would need a clustered environment (no down time on deploy) – Then we would want clusters on Test and Dev too • Most importantly, we need time to build and refine the processes and toolset….it will be a bumpy ride to begin with