Is there a way to develop/release features 'when ready' without using version-control branches?

My team has been using Continuous Integration for a while now, using the 'everything goes in trunk' approach. We're investigating changing this practice to allow us to release individual features as soon as they are ready, without having to wait for other features to catch up (we have multiple teams working on different features at once). There are lots of examples on how to do this with branching strategies (branch per feature etc), using git a开发者_如何学运维nd the like, and that's probably my preferred approach. But we've been asked by the managers to at least investigate other options, because the worry is that a branching strategy could result in delayed integration points, which we want to avoid. I don't want this to get into a discussion on CI/branchging strategy though, so I'll try and be specific in my question.

Has anyone used any strategies for releasing features when ready, without running multiple version-control branches? For example, using Branching by Abstraction or some other means of having features with different states of 'readiness' in a single branch. If anyone has experience (good or bad) with this kind of approach I'd love to know.

The branching by abstraction mechanism don't scale easily for large projects with legacy architecture, because said "abstraction layer" isn't always easy/quick to introduce in order to isolate your changes.

However, the other idea mentioned in this article is a very few number of branches, with only commits representing an application ready to be deployed.
That is something a DVCS (Decentralized VCS like Git or Mercurial) can easily accommodate because of the publication mechanism (orthogonal to branching), and which allows to:

• not publish (not push) private commits made in a local repository (so you can branch/experiment as you want, and more importantly, you can rebase your work on top of official branches very often and very quickly to ensure your work don't diverge from a working application)
• publish (push) your work, once ready, only on a 'trunk' or a 'release' branch on a unique repository acting as the reference for all the revisions "ready to be deployed".

That don't prevent to have other intermediate repositories to push to, in order to share intermediate works, but since said work has been rebased locally on top of official branch, even that development effort can be deployed and tested.

Try a social engineering approach to your managers desire to not use branches - use GIT with each feature done in it's own GIT clone, and pushed into the release clone when it's ready. Have a CI clone to ensure that the teams developing the features.

So the work flow, starting a new feature is

Clone the CI repo implement feature, regularly pulling from the CI repo Final pull from CI repo, then push feature into CI Push feature from CI into release repo.

All the Feature commits can be rolled into one big one if needed, or otherwise tracked such that they can be easily selected for pushing though the system.

With this solution you will never need to make a branch.