Sometimes, that functionality will be consumed right away, and the test automation that is in place will cover any issues with the change. Other times, that code will not be exercised because the functionality is not yet complete. So how do you release partial functionality without breaking anything?
Martin Fowler has a great article that discusses some of this, and some great ideas on how to handle it.
There are many ways to do this, and it really depends on the application, and the type of work being done.
- Bottom to Top - Create your repository, then your service, and build upwards.
- API Versioning - If new features do not break your contract, or if you are versioning your contract, then you should be pretty isolated to go ahead and make the changes.
- Build Conditionals - The code is committed, but not compiled in.
- Runtime Conditionals - Using a feature toggle, the code path is not executed. One great pro for this is that you can provide overrides, via cookies or a session, to test and view the functionality. The challenge with these is the code pollution, and maintenance of the flags after they are no longer needed.
- Source Control Branching/Forking - I think this method is quickly falling away as a method for isolation. The longer a branch lives, the more unstable it will become, and the more it costs to maintain it. We want to be doing many small releases, not big ones. Big refactoring could be a good use case for this method.
No matter which methodology you choose, always make sure you have a good suite of tests to validate not just the current functionality, but the new functionality you are putting into place.
If you do not feel safe pushing that button to put code into production, your test coverage is not good enough!