Jan 12, 2011 at 9:49 PM
Edited Jan 12, 2011 at 9:50 PM
As I think about your first comment (Google Chrome Release) it seems that there are two concepts here:
- Development Process
- Release Process
It seems Google Chrome uses a modified interative, incremental (Agile) process for development. They have decided that each increment will be an overlapping eleven-week iteration (the first six weeks being development). Within that eleven-week timeframe
they add new functionality (features), perhaps fix bugs, test, and release an increment of working features.
That process could easily be mapped to Scrum. Martin Hinselwood has done an interesting blog on branching for Scrum:
http://geekswithblogs.net/hinshelm/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx. You will note that I had the opportunity to review this blog before it was published. It draws heavily from the Rangers Branching Guidance.
If you are familiar with Scrum, you probably know that you need to start with a set of features to develop (the Product Backlog). This is prioritzed and as many of the top-priority features as can be developed and shipped in one Sprint are then moved onto
the Sprint Backlog (during the Sprint Planning Session). Sprints are often 30-days in duration, but some are as short as two weeks, while some may go longer. You could, I argue, suggest that the Google Chrome development takes place as 6-week Sprints (after
You will often see the activities of a Sprint depicted as a circle - to show the iterative nature of Scrum software development. It starts with a Sprint planning meeting, where the Sprint backlog is agreed to. It proceeds unhindered by the stakeholders,
until the Sprint backlog is developed and ready to ship. This is followed by a Sprint retrospective, that takes a look back at what went well, and what did not go well. Following this, the next Sprint begins. If you wanted to look at this on a timeline, you
could *unwind* the circle and lay it on a straight timeline. The length of this timeline would correspond to the length you have chosen for a Sprint (typically 30-days)
From a branching perspective, there are two schools of thought. One - create a single Development branch as a full child of Main - which is where the Sprint Team works on development during a Sprint. At the end of the testing, this branch is merged back
down to Main (RI) to be stabilized for release. If you look at Martin's blog, you will see that the timeframe for a Sprint begins with the Sprint planning meeting. Most of the activities during the Sprint take place on the Development (Sprint) branch. But
the Sprint does not end when the Development (Sprint) branch is merged to Main. It ends when the Main branch is tested (stabilized) and then branched for Release. You would have one release branch per Sprint.
The second school of thought is the same as the first, EXCEPT you would have a new Development (Sprint) branch created each time a new Sprint begins. I happen to prefer the first approach (a Sprint branch that simply continues from one Sprint to another).
Martin makes the point that by having a single Sprint branch, you have continuous history for that branch.
The Sprint Branches in this example would correspond to the Dev branch in the Google Chrome presentation. The Main branch, as it is being stabilized, would correspond to the Beta branch in the Google Chrome presentation. Finally the Release branch would
correspond to the Stable Release branch in the Google Chrome Presentation.
Next we come to deployment.
I have always viewed support for multiple environments such as Feature Testing, Integration Testing, System Testing, User Acceptance Testing to be deployment issues, not branching issues. By that I mean that I don't necessarily have a need to build a QA
branch in order allow my QA team to test the code in mhy Feature branch. I deploy the code from the Feature branch to the QA environment. I can control how often and when I do this deployment. In this way I can also associate bugs from QA with the specific
deployment (which might be labeled in the associated branch).
So, back to the Google Chrome scenario. They talk about the concept of *channels*. Channels, to me are deployment options. Here, Google allows customers to subscribe to one of three channels: Dev, Beta, or Release. All this means, in my view is that you
have three Drop locations which customers can subscribe to. A Dev drop location, a Beta drop location, and a Release drop location. When Google *drops* a new deployment into one of these drop locations, your subscription to update from the corresponding channel
will bring these changes to your environment.
What is different here from a typical environment? They allow you to subscribe to features in Development *before* they have been Beta tested. Or to features in Beta test *before* they are ready for Release. Presumably there is increased risk and less stability
when you subscribe to the Beta channel and even more risk and less stability when you subscribe to the Dev channel. This does not, in my view, mean you would do a daily drop from Dev into the Dev Drop location and make it available to the subscribers to the
Dev channel. What it does mean is that roughly six weeks after a dev cycle begins, when the code is branched to Beta, the Dev code can be dropped into the Dev channel. Then after the code in Beta has been tested, perhaps it is dropped weekly into the Beta
channel. Finally when the code is ready for release, it is branched for Release and dropped into the Release channel.
The key is code must be feature complete and tested in the Dev channel, while it can be incrementally dropped on a weekly basis from the Beta channel, and then dropped into the Release channel. The full timeline for a Google Release is approximately eleven
weeks (six in Dev, and five in Beta). It is agile, but takes place on a longer cycle than typical Scrum projects.
I will take a look at Flickr to see how it influences my thinking next.
VS ALM Ranger