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 WorkflowReady to deploy code
4. A Proposed WorkflowReady to deploy code Listens for changes
5. A Proposed WorkflowReady to deploy code Code Change Triggers Build Listens for changes
6. A Proposed WorkflowReady to deploy code Code Change Triggers Build Listens for changes Successful build triggers deploy script
7. We Already Have These Code Change Triggers BuildListens 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 hellReady 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 hellReady 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 Dev1. A repo has a branch for each environment – i.e. cre_data_tier would have 1 repo with 3 branches2. The repo and branches are cloned onto your local machine – every clone has a complete copy of the repo3. Developers would only branch from and merge into Dev
11. Adding a New Feature Master Test Dev new-feature1. Developer branches off Dev and commits to that branch.
12. But Wait! There’s a Production Bug! Master Test Dev hot-fix new-feature1. Developer goes back to Dev and makes another branch.
13. But Wait! There’s a Production Bug! Master Test Dev hot-fix new-feature1. 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 WorkflowReady 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