Our Continuous Delivery Process

A colleague of mine asked if I and a teammate of mine from my previous project could organize a small openspaceish tech talk on continuous delivery after our company's monthly meeting. To advertise it I drew a process diagram of our continuous delivery process:

1. Teamsters pick up a new feature to implement from the features on our sprint board.
2. They create a local or remote branch for the feature.
3. They edit the text files in the source repository. This is also known as "programming".
4. When the feature is ready the branch is pushed to the master branch in our git master repository.
5. Hudson builds and tests a new version on every commit to master including all integration tests and Webdriver based browser tests. If the build is successful, new version of our application is deployed to a repository.
6. Hudson is also used to deploy the latest successfully built version to production very early in the morning.

In haste and looking at the process through tool-glasses (mainly git-glasses) I forgot our step #3.5 which contains all the human process parts of our Definition of Done occurring between stages three and four: GUI reviews, exploratory testing, mini-demo to customer and customer acceptance of the feature.

So, compared to the well described and indeed very good git flow branching model we have a much simpler model with just master plus feature and fix branches and no develop or release branches as they have no meaning to us. This mainly because we only have one installation and one release of the application at a time running and we try to keep the number of features under development in one or two at any given time.