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