Git & Continuous Deployment
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
A Proposed Workflow
Ready to deploy code
A Proposed Workflow
Ready to deploy code
Listens for changes
A Proposed Workflow
Ready to deploy code
Listens for changes
Code Change Triggers Build
A Proposed Workflow
Ready to deploy code
Listens for changes
Code Change Triggers Build
Successful build triggers deploy script
We Already Have These
Listens for changes
Code Change Triggers Build
Successful build triggers deploy script
Code Isn’t Always Ready to Deploy
Ready to deploy code
SVN requires tradeoffs to work with CD1. Use SVN branching and merging…you’ll
pay in merge hell2. Only develop on trunk, but only commit
when your code is production ready . Not reasonable!
Code Isn’t Always Ready to Deploy
Ready to deploy code
SVN requires tradeoffs to work with CD1. Use SVN branching and merging…you’ll
pay in merge hell2. 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 mergingHowever…1. 2nd Class Citizen on Windows2. 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
A Git Development Model
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
Master
Test
Dev
Adding a New Feature
1. Developer branches off Dev and commits to that branch.
Master
Test
Dev
new-feature
But Wait! There’s a Production Bug!
1. Developer goes back to Dev and makes another branch.
Master
Test
Dev
new-feature
hot-fix
But Wait! There’s a Production Bug!
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.
Master
Test
Dev
new-feature
hot-fix
Disaster Averted…back to work
• 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
Master
Test
Dev
new-feature
hot-fix
A Proposed Workflow
Ready to deploy code
Listens for changes
Code Change Triggers Build
Successful build triggers deploy script
Why?
• Why would we want to do continuous deployment, or why use Git?– Why?• Why?
– Why?» Why?
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