Maintaining releases/branches in an "agile" rhythm ?

Question

We have a software product that evolves at the rhythm of clients' needs and of a more general roadmap.

Because we are in a SCRUM project environment, it happens very regurlarly that a new feature makes its way to the product, and then we are confronted with the choice of:

• implementing this feature in an already released branch (not really the point of having a branch, then)
• making a new branch - but then we have a branch every three weeks, and it is just not maintanable anymore

Not releasing the new feature is not an option, the clients don't want to wait for a long term milestone plan to get the features they want, and it's not always faisible to move the feature in a client module - sometimes we need to change the core of the product...

Has anyone any feedback on a good practice given those kind of constraints ?

Answer 1

A new branch like( 'new_feature_branch') is there to materialize a development effort which is not compatible with the current branch (like 'release_branch')

So if your current release_branch is not very active, you can use it for the new feature (provided you define a label before developing this new feature, in case you need to cancel that process and go back to the state previous this new feature)

Making a new branch can be a good solution provided it is merged back on a regular basis (every 3 weeks) on the release branch, and then left out. It is especially recommended if you have some activities on the release_branch (like some hot bug-fixing). then the two efforts need to be kept separated.

Basically, it all comes down to your merge workflow definition.

Leave comments if you want me to detail some options you feel I did not address enough in depth.

Answer 2

I'd suggest the following, which we use in my current environment: treat the unplanned feature like you would a security fix.

• Each planned release (e.g. 3.0, 3.1) gets its own version number, and its own tag in source code. After it's released, you don't touch it.
• New features after a planned release go into the next planned release (e.g. 3.2)
• If you must modify a released version of the code, it's an "unplanned release" and gets a patch version number (e.g. 3.1.1, 3.1.2). All changes:
  • Get implemented in a new branch based off of the latest patch to that release (e.g. 3.1.1 is created from 3.1.0, 3.1.2 is created from 3.1.1)
  • Are immediately merged to trunk, so they also get into the next planned release
• After implementing the unplanned feature, you turn the branch into a tag (aka don't touch it anymore) and go back to working in the trunk.

This way, each unplanned feature gets a branch, but only long enough to make a new release and merge into trunk. You do almost all of your work in one place - trunk - and don't have lots of merging work to do.

Answer 3

In my office we are typically working off of 3 branches at any given point in time.

• Release: This is where the code that is currently deployed is tagged and stored. If we need to do any critical bug fixes this is where work is done. When deployed we typically increment the hotfix portion of the tag (i.e. 1.19.0 -> 1.19.1).
• QA: This is where the code that is getting ready for customers is tagged and stored. This branch is used when we are starting on new work and have some code that is currently being tested by QA in preparation for the next delivery.
• Main: This is where all new work is done.

In rare occasions where we need to be developing in a fourth line (due to very tight release schedules), we will occasionally open up our sandbox line of code. Though more typically we will just have a single developer work in isolation and not check in until the main line has been cleared.

With the branching strategy above, we've been able to make major feature changes with a delivery at the end of every sprint.

Answer 4

It doesn't sounds like you are really living in a Scrum environment. Scrum requires the team to be DONE at the end of every Sprint, which is supposed to not last longer than four weeks (more likely one to two weeks). So, every couple of weeks, you should have a fully tested, running, potentially deployable system, anyway.

The only way I know to do that is to have comprehensive, fully automated suites of both customer and developer tests (like Extreme Programming prescribes).

I'm not sure why you'd need branches in this case, but I also don't understand why it wouldn't be maintainable. In my experience, the shorterlived a branch, the better.