I just came up with a new development/release process for a particular product at work. It's specifically aimed at a product that has only one live deployment and one test deployment (a web app we developed for a customer). So far, deployment has been a pretty big pain because the customer will have us implement a feature, and we'll finish the feature to the point of being Bug Free(TM) and merge it into trunk, but then when it comes time to deploy, the customer will tell us to deploy feature A and B but not *this* feature (for various reasons outside the scope of this post :). So far this has been done by updating the live code to the latest version and then commenting out individual bits with new features. So far, this has been tedious and error-prone, so I've been trying to think of a better way.
This is what I'm going to start trying to do:
In SVN, we will have "trunk" and "deployment". All development is done in individual, short-lived branches (which we've done to some degree so far, and I have seen others do with fairly good results). When we want to put it on the testing machine, we merge to trunk. When we want to put it on the live site, a well-defined deployment-manager merges the branch with the deployment tree (important to note is that the changes _don't_ come from trunk, but from the individual branches).
This way, when we need to deploy feature A and B but not C, DeploymentManager simply merges A and B and restarts the server.
This is all fine and dandy and, assuming that 100%-branch-development works, doesn't appear to have any flaws (apart from having a fairly high overhead, but that's OK for our situation).
One thing I'm still worried about is the 100%-branch-development methodology, though. I can see the following situation arising occasionally:
A new feature is developed in branch A, but that feature requires some new framework-features as well (or a refactoring, or just a new utility function), so the new framework-feature is committed to branch A. Another developer starts branch B before that first branch is merged. The second developer decides that Branch B would benefit from the framework-feature in branch A. What does he do?
* Simply wait for branch A. Hopefully it will be merged soon enough, and branch B can be copied from trunk after that merge.
* Developer A can be asked to merge his framework-feature into trunk but keep his user-feature in the branch. This would be tedious and be pretty high-overhead, but I suppose it's acceptable if it's urgent enough or branch A's feature keeps having its requirements changed.
Other ideas, like merging branch A to branch B, or branching B *from* A, somewhat conflict with the merging process laid out for trunk/deployment.
Anyway, that was nice, long, and boring. I'm going to just run with this idea for a few weeks and see how things go. Maybe I won't run into any of the nasty situations that I'm thinking of, or they'll be so rare that they're not too much of a pain to work around. If anyone has any thoughts about the second half of this post, I'd love to hear them.
Now, I need to get around to writing that bloody OSDC proposal.