As a small team, we don’t have the luxury of dedicated release engineers and thus need to automate our build as much as possible. To do this we use git branches, CruiseControl.rb and some nifty shell scripts to keep new code flowing. Coupled with the automation, we also have a weekly build master rotation where one member of the dev team shields the rest from tracking down build failures.
Ok, a picture is worth a thousand words so here’s our code flow (everything green is automated):
Developers will typically workout out of the DEVELOPMENT branch so this is where new code begins flowing through the system. We find that it’s good practice to link submissions to GitHub issues for management & deploy tracking. The changes then get pulled intoSTAGING which is the continuous build branch for automated testing. We like CruiseControl.rb because it’s light weight & low maintenance. If tests fail, the build master is notified and he can track down the right person to fix the failing test in staging. Once the build is green, the qualified code gets pushed to MASTER which is the production branch behind pubget.com. Since the master branch is considered the healthiest, it feeds down into development and any other project branches that may exist. At this point every branch now has that latest code change and the process begins again.
Too many words? Here’s the short flow:
This process has helped in a bunch of ways:
Ok, a picture is worth a thousand words so here’s our code flow (everything green is automated):
Too many words? Here’s the short flow:
- devs submit to development
- changes are tested in staging
- qualified changes get pushed to master
- development & special project branches stay close to shore through master
This process has helped in a bunch of ways:
- developers submit code and trust that it will be qualified, deployed & propagated to all branches
- developers stay productive even when the build is broken
- we have a production branch where we can quickly apply a hotfix if needed
