Introduction
Deploying code while working in a team can be tricky. If you have multiple developers working on the same repository orchestrating the feature release becomes problematic. Teams usually ask themselves whether a they can deploy to production their current dev branch and whether such a deploy process will be safe and won’t break existing features and/or introduce non working untested new features to the production environment. Features flags can be a mechanism that allow safe deployment of entire branches thus reducing the lead time of features from the developer’s laptop to the end user. This in turn results in more features deployed per time frame, enabling unlocking more value for users and growing the business.
Problem Description
When multiple developers work on the same code base they encounter several challenges. Among those are ensuring code consistency in terms of quality, test ability and readability; avoiding code conflicts across features; usage of shared resources (such as deployment pipelines) and so forth. One of the main challenges is deciding whether the whole development branch can be promoted to release and production environments. Each feature can be in different stages of progress:
- Features covered with tests, manually tested and ready to deploy
- Features covered with tests but still not tested manually
- Features manually tested but were returned to the developer with bugs
- Many many other scenarios
In this situation in order to deploy feature A and B which are in ready to deploy state we need for features C and D (that lets assume for the discussion were tested but bugs were found) to be done. This holds us back in terms of adding value to the end customers. Several solutions exist to this scenario
Possible Solutions
Wait
A trivial solution is just to wait for the features to be ready. Unfortunately as stated above this holds us back from delivering value for our users. However, unfortunately many organizations stick to this method.
Git Cherry Pick
We can’t deploy the whole branch? No problem. We will cherry pick the relevant commits and deploy only them. Sounds good but it is really not. This is an error prone and hazardous approach. It’s easy to forget a commit or forget that a commit can influence a different feature. In addition, when later we commit the whole branch we might need to address conflicts in code between the version on production and the last development branch. This approach should be used in rare cases when you need to deploy a hotfix to production or in well carved and isolated features.
Comment Out the Features That Are Not Ready
Yes, we can comment out the code of the features that are not ready and deploy only the ready ones. However, this approach as the solution of using git cherry pick above has its risks and is error prone. We can accidently forget to comment out relevant code, or comment code that is relevant for a different feature. In addition, when the feature is ready finally for deployment we will have to go again over the code and uncomment it. Thus introducing a second chance for a mistake that will entail commenting or uncommenting wrong lines of code and a possible conflict between the code on production and the current development branch.
Split the repository
Another possible solution is to split the repository the developers are working on to several repositories. Thus embracing in a way the microservices approach. This way we reduce the number of inter connected features that need to be done so we can deploy the whole branch. This is a viable solution, however it has its costs and drawbacks. Orchestration and coordination costs in terms of development and devops rise considerably which working with microservices. In respect to DevOps each repository should have its own dockerfile, container, deploy pipeline and so forth. Likewise, in terms of development now to implement a feature you might need to involve several code bases. Each request will go through several checkpoints. This makes development and debugging distributed and thus harder. In general, there is a limit to how many microservices you can create without making the whole thing unmanageable for your time size.
Feature Flags to The Rescue
Truth should be told that like all the other solutions listed above, feature flags are not a silver bullet. They won’t solve all your problems but they can be a welcome addition to your toolbox of available solutions. A feature flag is basically a simple conditional statement that according to which we “switch” (pun intended) a feature on or off. It can be as simple as
if (feature is ready) {
lines of code
}Feature Flags vs Comment Out/Change Code Later
You might rightfully ask what is the difference between this code snippet and this solution and just commenting the code out as described above. The difference is that the condition for enabling the feature’s functionality is stored in a remote server (usually called a config server) with the features’ name, environment and and on/off flag. Thus to parse the condition your code will access the remote server, check the flag’s value for your current environment and place it in the appropriate line of code. This basically enables us a centralized approach to handling features and enabling/disabling them with a click of a button without any code changes.
Push The Button
This way when a feature is not ready the flag is set to “Off” and you can safely deploy all the features and bug fixes in your development branch. Once the feature was tested and you feel confident just go to the config server and switch it to “On” on production environment.
Possible Config Server Solutions
There are many possible solutions for storing this kind of feature configuration. Some of the popular vendors you can use:
- AWS appConfig
- Advantages: cloud based, minimal setup time, stable
- Disadvanatages: costs money and locks you in the AWS universe
- Spring Cloud Config
- Advantages: open source, can be installed on prem, integrates great with your Java Spring based applications
- Disadvantages: needs to be configured, hosted (if you don’t use the cloud version) and maintained
- Apache ZooKeeper: Originally designed for distributed coordination, ZooKeeper can also be used as a distributed configuration store.
Conclusion
Deploying code base written by multiple developers is challenging. Features are in different states in their development process. It is hard to feel confident that everything will work when you deploy to a different environment. Moreover, as discussed this prevents us from unlokcing more value for our customers. Several solutions exist to this problem. One of them is using feature flags. In this article I’ve discussed the ways in which feature flags can help you with deploying and managing features’ states’. Lastly, I’ve explained how feature flags are different from the other solutions and listed some of the vendors you can use if you want to implement feature flags in your organization.