This project has moved and is read-only. For the latest updates, please go here.

Handling Content Changes Selectively Released To Production

Mar 8, 2011 at 9:52 PM

Hi All,


I have a scenario I'd like some best practice advice on.

We have a large public facing website.  We have 3 development teams working on the website, each in their own project/feature branch, merged from a Main (or as well call it Trunk).

This is all working well and apart from a project which does major re-organisation of the codebase the merge's are not to bad.  We only merge from a development branch to the Main when that project is the next to be released to production.

From Main we also have a Production branch, which represents what is currently in Production allowing us to perform hotfixes etc.

The issue we have is we also have a UI team which make daily changes to content, javascript, css etc on the website.

From our Production branch we have created a child branch called UI.

The UI team work on TFS workitems and check in their code against a workitem.  When a particular workitem is ready for production, all the files with all changesets associated with that workitem are released into production.

The problem we have is then merging these changesets back to the Production branch.  We fall into the scenario of cherry picking changesets and all the associated problems.  Especially when multiple changesets linked to the same workitem have the same file.

We cannot just select all UI branch changes and merge to production as not all of the inprogress work items actually have been released to production yet.

Does anyone have any thoughts or suggestions on how best we should handle this scenario?


Thanks

Rick

Mar 9, 2011 at 1:27 AM

Hi Rick,

This is a topic I am in the middle of blogging about. In my scenario, I have a Scrum project. A team has accepted a number of Product Backlog Items (PBIs) onto their Sprint Backlog (SBIs). At the beginning of the Sprint, based on their previous velocity, the team was confident they would be able to complete all of the SBIs in their backlog. However, towards the end of the Sprint, it becomes apparent that one or more of the SBIs will not be finished. The team will not be allowed to extend the Sprint, and they do not want to merge unfinished SBIs into their Main branch for release.

As I see it, there are three options. If the Sprint team is developing on the same branch (for example, SprintBranch1), then there is not much choice at the end of the Sprint but to do the Cherry Picking merge from SprintBranch1 to Main of *only* the completed work (the finished SBIs, or user stories).

There are a couple of alternatives that one can employ, but essentially this involves making a decision at the beginning of the Sprint to work differently. One approach, which I do not necessarily prefer, is that each member of the team will defer checking in changes for an SBI (or feature) until it is clear that this SBI will be finished before the end of the Sprint. Since we do not want to go for an extended period of time without getting these changes onto the server, we ask each member of the team to shelve their changes at the end of each day. This, at least, captures their changes on the server in the event that the Team member's laptop is stolen, or its hard drive crashes, etc.

The alternative approach, which I tend to prefer, is to have each member of the Team working on their own development branch. If you have seven Team members and each one is working on one SBI at a time, you could have seven development branches (SprintBranch1 to SprintBranch7). Each Team member checks in their changes as they would normally. When they get to point that an SBI is complete and ready to be integrated with other completed features or SBIs for the Sprint, then you would merge (RI) this SBI from the SprintBranchx to Main. This would open up the SprintBranch for the next SBI on the backlog. Each member of the Team works in this fashion. When a feature or SBI is complete, it is merged (RI) to Main and then work continues in that branch on another feature. At the end of the Sprint, all of the completed features (SBIs) are merged to Main for release (as the incremental working increment of potentially shippable code). Any unfinished work remains in the Sprint branch and is carried over to the next (or a future Sprint).

Both of these options require planning ahead and allowing for the possibility of unfinished features in a Sprint. One uses fewer development branches and relies on Shelving changes until a feature is complete. The second uses more branches for development and only merges a feature from a development branch to Main when the feature is complete.

I prefer the second approach for a variety of reasons. First, it avoids cherry picking changes at the end of a Sprint which can be very challenging. How do you avoid picking too many changesets and / or too few. What happens if changes to more than one feature or SBI were checked in together and later we discover that one feature is completed and the other is not. How do you split a changeset to cherry pick only part of it.  I often use the analogy of baking a cake. You follow the recipe (almost). In a bowl mix two cups of flour, one Cup of milk, two teaspoons of sugar, a half-teaspoon of salt, two teaspoons of baking powder and three eggs. Mix thoroughly. Wait. Now you discover you should only have added two eggs. How do you remove one egg from the cake batter after it is mixed in?

The second option (more branches) will give you more granular changesets that allow you to track the progress of the project and feature more closely. Rather than having only one *big bang* changeset at the end of the feature's development, you have a normal progression of changesets that occur on a daily basis (or more frequently).

I recently presented this approach to a group of developers at a conference. As a Certified Scrum Master I find that not many Scrum teams have thought the implications of Sprint teams, Sprints, and the possibility of unfinished features at the end of a Sprint. The implications on Source Control Managemt (SCM) have not been well understood in the Scrum community (Yet!!!)

Although this scenario is somewhat different from yours, I think there may some suggestions here that help you.

Regards,
Bill Heys
VS ALM Ranger