I lead a development team and I want to release our product as often as possible (Continuous Delivery).
In many cases, we have to implement a feature that takes longer to implement than the time between releases. I still want people to commit their code on a daily basis (Continuous Integration).
Many times implementing a new feature requires existing feature to be changed and the existing features, of course, still need to work, even if the new feature is not finished yet.
If the developer uses the right approach, they can adjust existing features carefully and all of the above is not a problem.
However, what IS the right approach actually? My own programming attuned mind tells me what to do for each individual case, but I need to learn more and I need some reading material that I can read and refer team members to read. Or any other method of learning the right way to learn this approach will do.
So that's the question. How do I make sure team members learn the right approach to implement half a feature?
I've searched for people claiming to have strategies regarding this, but haven't found it yet, except people writing a few random thoughts on the topic. Perhaps I'm not using the right search words or perhaps no one has made any authoritative guidelines on this.
Best Answer
I take a different view from the other answers on here already. I agree with you that you want to integrate changes from developers as soon as possible, and to keep testing the combined mix of code.
However, I do not agree that its right to ship code developed this morning, just because we are releasing this afternoon. That is a recipe for disappointed customers.
The solution is to have branches in your version control tree, and that you have a separate process to promote verified deltas from the develop branch to the release branch.
That way you get the best of both worlds. You have developers doing continuous integration, and the advantages that brings, you have stable code shipping regularly to the customer, and you have a new process that tests completed features in the developer branch, and if they pass testing make them part of the released product.
There are two tools that I am familiar that support these kind of processes well. If your development structure is simple, then git, with git-flow implements a good branching structure that works well in small to medium sized teams (perhaps 20 developers).
For larger development teams, or where a more complex branching strategy is needed to support multiple 'spins' of your product, accurrev is the best there is. The developers not involved in managing the changes will complain that its harder than sub-version etc... but it does support complex development environments.