Something about this seems orthogonal to me. There's nothing about dvcs itself that implies a lack of fluidity in a codebase, is there?
In a rough attempt to get down to first principles, CI means you need to be able to deploy a codebase at anytime. Feature development means that codebase needs to be ever-changing. Successful deployment means the codebase needs to be at a level of guaranteed quality.
This means that the quality of a "change" needs to be guaranteed to some level before it is merged to the deployment branch.
So right there, that implies the need for "changes" to be developed and quality-checked somewhere other than on the deployment branch.
I think that takes us pretty inexorably to the practice of branching the codebase, developing there, quality-checking there, and also merging from the deployment branch into the feature branch as the deployment branch changes.
So what's left is qualifying what is meant by "change". Is it one feature? A story? A functionality layer? That can be harder to decide on. Agile says it should be a ui-focused story, but sometimes stories are epics (like a simple form submission that somehow implies several SOA services be set up to make it work). So I think that means we can still do functional dependency analysis and shrink stories down to smaller functional steps, sometimes.
The key is to keep stories/features small enough so that they aren't in progress for weeks at a time. When you're working on a feature and then are faced with a massive merge from the deployment branch, that's where things get messed up.
In a rough attempt to get down to first principles, CI means you need to be able to deploy a codebase at anytime. Feature development means that codebase needs to be ever-changing. Successful deployment means the codebase needs to be at a level of guaranteed quality.
This means that the quality of a "change" needs to be guaranteed to some level before it is merged to the deployment branch.
So right there, that implies the need for "changes" to be developed and quality-checked somewhere other than on the deployment branch.
I think that takes us pretty inexorably to the practice of branching the codebase, developing there, quality-checking there, and also merging from the deployment branch into the feature branch as the deployment branch changes.
So what's left is qualifying what is meant by "change". Is it one feature? A story? A functionality layer? That can be harder to decide on. Agile says it should be a ui-focused story, but sometimes stories are epics (like a simple form submission that somehow implies several SOA services be set up to make it work). So I think that means we can still do functional dependency analysis and shrink stories down to smaller functional steps, sometimes.
The key is to keep stories/features small enough so that they aren't in progress for weeks at a time. When you're working on a feature and then are faced with a massive merge from the deployment branch, that's where things get messed up.