In a recent blog post on CI/CD, my colleague Martin mentioned a useful feature called feature flags. As he suggested, thanks to it, we can hide new code from certain users in the production environment. However, developers or other select people can continue to access, test, and develop it until it’s fully ready for the public.
How do feature flags help us develop Crossuite?
- We can react to changes in client requirements faster
If it’s decided that a new functionality should only be published later, let’s say for marketing reasons, we can immediately turn it off and then return to it again. Thus, the client gains better control over the software and we in turn have the ability to respond to their needs flexibly.
- We can test new functionalities on a small target group
This gives us valuable feedback before we decide to make the functionality available to all users. In this way, we can check how customers will react to the news in the app and see if it’s really useful to them.
- We’re able to fix errors more efficiently
If an error occurs in a feature, we simply turn it off using a feature flag until it’s fixed. In this way, we have the ability to minimize the impact of an error on users and at the same time prepare a fix without having to release a new version of the software.
- New functionalities can be implemented and checked gradually
Instead of running all the new features at once and then spending a few hours testing them, we can publish them gradually. This will result in a series of small updates that can be checked effectively. In addition, users get a good feeling that the software offers them something new every now and then.
Where have we used feature flags before?
We expected the introduction of feature flags into our development to result in more frequent integration of code into the main branch, and therefore a higher frequency of deployments to production. Since then, we’ve been using them regularly and so far it has been very successful. As evidence, I’ve chosen three specific examples:
Integration of Zoom meetings
The company offering Zoom requires that the use and deployment of the platform be reviewed by its employees. Only then will it verify the application for use in production. In order for the company’s employee to test the Zoom integration on Crossuite, we used the feature flag. We’ve only enabled integration on one account that the reviewer has signed in to, successfully tested and then approved.
Use of new technology for search
The search technology (SQL) used by the system until now was no longer sufficient in terms of performance or results. We decided to replace it with a new one – Elasticsearch engine. We implemented it through a feature flag that allowed us to switch between these technologies and monitor their effectiveness. At the same time, we only allowed Elasticsearch for a select group of users, which allowed us to test it before we made it available to everyone.
(Un)successful release of a diary printing functionality
Even though we try to cover as much code as possible with automated tests and then test new functionalities manually, a problem may always appear after deployment that we failed to catch during development and testing. This happened, for example, after the publication of the diary printing functionality, which offers clinics the opportunity to print a calendar of events in various configurations. The functionality didn’t work for one user at all. Instead of reverting the entire version, we decided to temporarily disable printing using a feature flag. Subsequently, we fixed the bug within one day, released and enabled printing again.
How do we implement feature flags?
We currently set the function manually in the database for each environment. However, we’d like to prepare a simple UI for managing feature flags soon, or implement a ready-made solution to optimise the process. We’ll definitely inform you about the results of our work in monthly digital inspirations, so don’t forget to continue following us.
