In a lot of organisations, release and happen at the same time. That is to say that the release of a new feature to your user base is triggered by deploying your application to the server. Doing it this way is just a good way of making deployments scary and releases risky. deployment Let’s be clear on the two processes: The process of putting code into a specific environment (The production environment in this case). The process of informing and allowing customers to use a new feature of your application. Deployment: Release: Note that the former of these is a process handled entirely by the technical team whilst the latter is a decision. technical business Deploying code to production before the release of the features contained has multiple advantages. Firstly it allows you to smoke test the new feature in production without the load associated with a new feature release. Just after announcing your newest and greatest feature is not a good time for things to go wrong. Additionally it allows you to the new feature. This is where the feature is fully active at production-like loads without being visible to the customer. For example, before Facebook launched Messaging to their web platform, they dark launched the feature and programmatically had thousands of users sending each other messages without the users ever knowing. This allowed the engineers to get real data from a real production environment from real users without anyone being any the wiser. Dark Launch One way to effectively the features in the code base from the features in the user-facing product is to use . These are an abstraction which allow the application to know which features should be available and, perhaps more excitingly, decouple feature toggles to whom. It’s certainly possible to have simple on/off style feature toggles but you can also have a 1% feature toggle to display the feature to 1% of your users or perhaps a feature toggle that targets users under the age 18. These are decisions that can and should be made at a with minimal technical intervention**.** business level Feature toggles do have a good technical use though in that they allow you to disable certain features when your service is under heavy load or if a critical bug is discovered. Finally, and perhaps most importantly, this decoupling of deployment and release allows you to deploy much more often. Deployment of code should be a low-risk, routine affair and the only way to get to that point is to do it as often as possible, ideally every time the code is changed. Once deployment is an almost boring consequence of your daily work and all your work is behind various feature toggles you mitigate the need for long-lived feature branches and can start practicing hich is a topic for a future article… trunk-based development, w If you liked this article please remember to give it some applause to make sure more people get to read it! Steven Poulton is a web developer and technical architect living in Manchester, England. In his spare time he likes to make indie music, make indie games and play with his indie cats.
