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.

  • "existing features, of course, still need to work" -- depending on the context, term for a requirement like this could be backward compatibility or absence of regression bugs
    – gnat
    Sep 10, 2013 at 8:56
  • 1
  • 1
    Different types of automated testing may reduce the risk of errors in code changes. Check. I'm looking for the approach to use as a developer that has to implement a large feature that may involve 75% changes in existing code and 26% new code (the extra percent is there for added mystery). Sep 10, 2013 at 13:30
  • 1
    @Niels:You must have some amazing developers for them to be able to have working code at the end of every day that can be checked into the main branch and passes all the tests. Either that or they only get bare-bones minimum done so they are in a position to check in their code by the end of the day.
    – Dunk
    Sep 10, 2013 at 13:45
  • wouldn't they call that a "Feature Branch". You make your changes in the branch and then merge the branch back into the master when the feature is finished. You should not be presenting half-implemented features in demos, so I don't see why this wouldn't work.
    – deltree
    Sep 10, 2013 at 16:46

4 Answers 4


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.

  • I would be very interested to know more about the branching strategy you are referring to. Do you have a link to an article or something else that explains more in-depth the concept you are referring to? Sep 10, 2013 at 19:33
  • 2
    here is nvie.com/posts/a-successful-git-branching-model for git flow Sep 11, 2013 at 7:55
  • The key characteristic of git flow is its clearly defined branching strategy, which makes it a good choice for a product that only has one release to produce. Accurrev does not enforce a branching strategy, but has the flexibility and provides the tools to effectively manage a much more complex tree of branches. Sep 11, 2013 at 7:59

There are two problems here: one is implementing half a feature; the other is keeping the shipping product working during continuous development.

Implementing half a feature

A strong overarching design will help with this. This lets you implement the feature with its boundaries clearly defined--e.g., APIs to adjacent bits of code, expectations about data structures, and an understanding of how and when the implemented code will be called.

Testing can include mocked up versions of the code for the other parts of the feature; this helps smooth the transition when you go to implement the second half.

Keeping the shipping product working

There are a handful of options here:

  1. Turn the feature 'off' in the shipped product. Just because the code is in the product doesn't mean it has to be executed or presented to users. The downside is that you will not be delivering incremental value to your users, and you will not be getting feedback.
  2. Reveal the edges of the feature to your users. Show what you've got, and provide some indication of what's to come.
  3. Let users switch between new and old functionality. This sometimes requires maintaining two code paths that are end-user-ready.

Finally, if you are having trouble with any of these solutions, consider whether you have split the feature along the right boundaries. If you sliced things a different way, would it be easier to pull apart?

  • It's easy enough to switch off a new feature that's not completely ready. That's a good advice. So the core issue in the shipped product is that EXISTING features may break if people don't use the right approach when they alter existing code. Sep 10, 2013 at 13:37
  • 2
    That's where good testing comes in. If you don't have decent coverage for your code base, perhaps this could be a trigger for that effort? Sep 10, 2013 at 14:10
  • But can the answer to my question simply be "perform good code practice and make unit tests" etc...? Sep 10, 2013 at 14:25

How do I make sure team members learn the right approach to implement half a feature?

By teaching them. (duh)

Learning will involve iteration: trying something, seeing how it works, and then modifying their approach to achieve better results. For this sort of thing, I would advocate design/code reviews. You get to see how the half-feature is designed/implemented and have the opportunity to give feedback. "This and that won't work because they'll break our CI; how about XYZ?", "Good job here, that's really clean."

Doing the reviews as a team will help everyone learn what you already intuitively know.

  • I'm totally on board with this. But just like I can teach someone how to make unit tests OR refer them to the book "The art of unit testing" - is there a similar resource I can refer to for this topic? Sep 10, 2013 at 13:35

The biggest thing that will help you here is having a good separation of concerns so that as far as possible one area of code does not interfere with another.

This is a place where using Dependency Injection and programming to the interface really helps, so that you can have your current implementation of ISupportingFeature on the site and then when you need to create INewFeature that depends on a different implementation, you can just develop with the new implementation and maintain the existing one in production until it is well tested and ready to go live. Assuming you have your DI working off a configuration system of some kind this will allow you to have the same code in parallel in your system and be using stable code at all times.

In fact this configuration approach is described by Martin Fowler as a Feature Toggle.

Of course, the problem only arises if you are deploying all of the code all of the time. This is precisely the type of scenario for which feature branches were designed and although I acknowledge that Mr. Fowler frowns on them, I don't know that they are all that bad, especially if they are created and used in a planned and thought-through way.

  • I am under the impression that committing all the code to the same branch and deploying all my code all the time is part of a good strategy of continuous integration? Sep 10, 2013 at 13:33
  • Reading more into Continuous Delivery, it is certainly a part of that. I wince somewhat at the thought of that, though - do you want to be deploying half-written code even if it should be de-activated? Maybe it works well in a scenario where security isn't important, but it sounds like a high-risk approach for a lot of application spaces. This probably marks me out as an old-fashioned security-hugging fuddy duddy, though.
    – glenatron
    Sep 10, 2013 at 14:54
  • There seems to be two competing strategies, where one has as single main branch and another has a branch for each task and lots of merges... I'm not sure what's best or right - or whether it hits the core of my questions. Sep 10, 2013 at 19:43
  • I think it depends a lot on the type of thing you are making- I would be more inclined towards branches if I had any priority on security and didn't want to risk actually deploying untested code where someone might find it or it could be accidentally enabled. So if I was running a bank site, I don't think CD would be the thing, but maybe if I was running a high-turnover website for casual/occasional visitors, it might be ideal.
    – glenatron
    Sep 11, 2013 at 10:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.