Tuesday, February 4, 2014

Releasing Code Without Breaking Anything

In the world of Continuous Delivery, engineers are making small changes and releasing those changes to their servers several times a day.

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.
  • UI Versioning - If your UI is decoupled from its back-end (it should be!), then you could layer additional JavaScript on top of your current code to "preview" the new functionality.  Some CMS systems will have a preview feature that could be leveraged.
  • 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.
Have I missed any?  What methods are you using and why?

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!

No comments:

Post a Comment