The document discusses using Git and continuous deployment workflows. It proposes a development model using Git branching where developers work on feature branches off a development branch. When a feature is ready, it is merged into development and then propagated to test and production branches. This allows code to be deployed frequently while separating stable and unstable code. Challenges with other version control systems like SVN are noted. Tools like scripts for multi-repo projects and automated deployments are suggested to enable continuous deployment with Git.

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