Branching for Agile Development
I was recently asked a question based on the following presentation from Google:
The main part of the article that interests me is the following:
"Anthony LaForge, the technical program manager at Google overseeing Chrome development, created this presentation to explain how Chrome’s development cycles work. Instead of a traditional software development cycle where features are crammed into each release or delay the release, Chrome puts out a new release no matter what every six weeks. If new features aren’t ready, they wait for the next release, just like waiting for the next scheduled train at Grand Central.
Another thing that speeds things along is that the Chrome browser is simultaneously developed along three different “channels” (dev, beta, and stable). Users can pick which one they are most comfortable with, and their browsers are updated automatically. New features are introduced first in the dev and beta channels, which merge with the stable channel as those features get patched and stabilized.
The versions start to blend together. The approach is more like updating a website than a piece of client software. The version numbers don’t really matter. What version of Amazon are you on? Exactly."
This model seems at odds with the branching guidance from the rangers....BUT Google ships this browser to Hundreds of MILLIONS of customers so it HAS to work. I'd love to get the rangers insight into how Google's model could be applied to TFS....we do enterprise click once development so our updates get pushed out to our employees rapidly and while branching has streamlined our "release" process, I'm curious about alternative models that produce and deliver software faster.
My response follows:
In looking at the Google Chrome Release presentation, it seems that there are two concepts here:
- Development Process
- Release Process
It seems Google Chrome uses a modified iterative, incremental (Agile) process for development. They have decided that each increment will be an eleven-week iteration. Within that eleven-week timeframe they add new functionality (features), perhaps fix bugs, test, and release an increment of working features. The first six weeks of each iteration is development. Since the iterations overlap, Google releases a new iteration every six weeks.
That process could easily be mapped to Scrum. Martin Hinselwood has done an interesting blog on branching for Scrum: https://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 a fashion).
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.
Regards,
Bill Heys
VS ALM Ranger
https://blogs.msdn.com/billheys
https://tfsbranchingguideiii.codeplex.com/
Comments
- Anonymous
January 12, 2011
thanks a lot,really nice blog,bravo!!rhodesmarket.blogspot.com - Anonymous
October 01, 2013
It would be nice to see in example (maybe picture) how the described branching model, which is rather theoretical, fits the declared purpose: "If new features aren’t ready, they wait for the next release, just like waiting for the next scheduled train at Grand Central." In other words, if file modifications – hundreds of them – contain both bug fixes and new features that aren't ready to go, then merging Dev and Main is going to be pretty sophisticated, isn't it?