A feature flag is provided by the DevOps tools, pipelines, and cloud providers, and it can be developed manually by a team as well. The story of a feature flag is as simple as a basic if...else block in the code that controls whether to grant access to a feature or not. Feature flags can be hardcoded features or soft conditional blocks that prevent access to a specific feature for a time.
Imagine a scenario where you must broadcast an update to your customers for a New Year or Black Friday deal. You cannot expect the customers to wait until the update has been pushed out to the online Android or iOS app stores to download and then use the discounts. Your users expect the benefits to be unlocked once the clock ticks 12. Another major problem is that the clock does not tick 12 across the globe at the same time. There are different time zones that the software needs to consider, and many other similar problems. With feature flags, we can easily control the values for the discounts from an external server.
This server acts as the hosting platform for the configuration values. After all, a feature flag is just a configuration value that is hosted elsewhere.
I have used several platforms that support feature flags. I personally like Alibaba Cloud Application Configuration Manager12 for its simplicity, features, and pricing model.
Other than Alibaba Cloud Application Configuration Manager, GitLab also offers feature flags.13 GitLab, however, offers this service as a paid plan;
it does not come with the free product. So, if you are a single developer with no back-up budgets, then GitLab feature flags might not be the right product for you. Apart from GitLab, Azure DevOps and other DevOps tools also provide support for feature flags. Best practices for the application of feature flags include the following:
• Do not overdo the feature. Use a manageable number of feature flags in your system. Your operations team needs to manage and remove the flags that are not necessary.
• Feature flags should be used to hide or abstract features that are meant to be staged. A feature flag should not be a replacement for conditional blocks for license checks.
You should use the store-provided license services, such as Google Play Licensing for Xamarin.
• Feature flags should be removed as soon as their underlying features are released to the public. This housekeeping task will help in the long run and produce maintainable results.
12 Learn more on the Alibaba Cloud website at www.alibabacloud.com/product/acm.
13 Learn more about GitLab and their support of Feature Flags for DevOps teams on their website at https://docs.gitlab.com/ee/user/project/operations/
feature_flags.html.
• You should use general configuration values and process their relative information on the client side. For example, you should use UTC time zones in the date and time values. This will enable your application to check whether to unlock a feature or apply a discount at runtime.
• You should listen to changes in the feature flag’s value asynchronously in the background. This will help you update the UI as soon as the changes are reflected in the online configuration storage.
• You should introduce percentage rollout to control the behavior more. Percentage rollouts can help you decrease the load on servers and test your features before all of your user base tries the feature.
Note that if you do not wish to use Alibaba Cloud Application
Configuration Manager, you can use an online resource storage service.14 Google Drive, OneDrive, and other online storage options are also valid.
You can create a simple JSON file that holds the data that your application connects to. This data can contain the configuration information for that instance in time.
14 You can also explore Firebase Remote Config, as it provides a good alternative.
Firebase, however, does not have an official SDK for C#, which is why I am not including it in this sample. You can check for more details on their official documentation at https://stackoverflow.com/questions/52514782/
firebase-remote-config-version-condition-is-disabled-for-unity-
Summary
Automation is the core of DevOps and it helps teams reach their goals of publishing features quickly. This chapter was about the ways in which teams can achieve scalable automation. There are no best solutions, only useful solutions in the DevOps market. In this chapter, I used Azure DevOps to demonstrate a few steps in DevOps, but you can use any other DevOps solution, such as GitLab or Jenkins.
The introduction of version control systems was necessary to understand how a DevOps pipeline gets triggered on changes. The most important aspect of DevOps is IaC, which is a way to control the infrastructure deployments. We looked at Azure Resource Manager, but there are several other options, like Alibaba Cloud ROS.
We also discussed the automation pipelines and the stages of DevOps and CI/CD. We created a new pipeline in Azure DevOps. Then we
connected our repository to DevOps and triggered a new build pipeline.
We also created a new Release pipeline to deploy the solution to Microsoft Azure. DevOps build pipelines can also be used to analyze code for bad code standards or for code that is ignoring the code policies of an organization.
Feature flags were also introduced. They can help development teams deploy features at their own pace and help operations teams control access to the features themselves. One thing you might notice is that I did not talk much about security in this chapter. Security is not the cherry on the top, instead it should be the DNA of the software, build servers, and production environments. That is what I focus on in the next chapter. I talk about security for build systems, and how you can verify that the deployment environments are safe from external access. I use several concepts introduced earlier and some new interesting topics as well.