Many organizations employ a complex deployment process where every code change has to go through a series of different steps in order to reach the production environment. This is typically due to organizational rules, which require many people to approve the deployment. The result is a big package with many updates to the code that is supposed to be deployed at once. At deployment time the level of stress rises drastically, as there often are unexpected errors – missing configurations, misunderstandings in the team, or special (not well-tested) scenarios. Moreover, if the deployment fails, it needs to be rolled back, which could be a painful process.

Deploy often

From a developer’s perspective, code is not supposed to stay in a repository, code is supposed to be in production. Every developer wants his code to be pushed to production as quickly as possible. What slows this down (or sometimes prevents from happening) are the intermediate phases of testing and verification that this code does what it is supposed to do. One strategy to decrease the stress at deployment time is do practice it more often. Instead of deploying one big package every 3rd month, you can do smaller deployments every 2nd week. This will put focus on a smaller amount of code changes and improve the testing process as fewer things will be tested at once.

Deployments vs. releases

When deploying often to production, one may bump into the plans of the marketing department. The marketing department, in one or another form, is responsible for promoting organization’s products and services to the world. If they have decided that а feature should be available on a specific date, you may not get approval to deploy it earlier. In order to find a solution in such situations, we need to distinguish two terms:

• a deployment is the process of putting code on a specific environment, typically production
• a release is the process of publishing / revealing a feature so that it is available for the users

Having these two separate processes, we can deploy often to production without releasing our features until we get a GO from the marketing team.

Feature toggles

Feature toggles are the way to manage whether a feature is available to the users. This is a simple list (kept in a database or a configuration file on the server) with on/off state for each feature. Developers are responsible for checking whether a specific feature is available in the list in order to reveal it to the users.

Conclusion

Feature toggles are a powerful tool to support small and often deployments when we want to be friends with the marketing department. By increasing the frequency and decreasing the size of our deployments, we create a safer and less stressful environment for changing the production code. In order to become good at something, you need to practice it often. 🙂