Yes to Keystoning, No to Branching

The Agile Environment

I have worked in my current job for nearly a year now. The R & D team's approach to development is as agile as possible; limiting work in progress, close collaboration between developers and testers, pair programming (or at least, peer code reviews), TDD, small checkins, continuous integration, collective code ownership, releasing to production quickly and often, reducing the feedback loop, scrumban, continuous process improvement.

Keystones

The release schedule of our main product is every fortnight; peripheral packages are released the week when our main product isn't being shipped. This means that sometimes our product ships with part-completed (but NEVER untested) features in it. These part-complete features are generally invisible to the user by their nature, sometimes a new database table, sometimes a new repository. These changes are designed to be used by the customer only when the keystone is deployed. As the name suggests, this is the final piece of the feature that allows it to be made visible and used by the customer. It's usually the UI component, but could also be code that's enabled via a config switch.

No Branch, No Merge

In the year I've been at the company, I can count on one hand the number of times we've branched the source code. Each time we have, it was to apply a hot patch to a release. We don't branch the code for concurrent feature development; everyone checks their code in to main / trunk. One reason for this is to avoid the all-too-common 'merge hell', trying to keep each branch up to date with the others' changes. If the code is branched and e.g. a 6 week feature is produced, there could well be thousands of code changes to merge, per branch, with the very real possibility of hundreds of merge conflicts. I have been responsible for merging releases of source code into a main branch, and it is not easy and it's certainly not pleasant. But most of all, it's not necessary.