As we all know, software developers may ease their development process by integrating their work as often as they can. It is also known that releasing frequently into production helps a lot. But developers and project stakeholders don’t want to expose half-developed features to their users. So, what happens in this case?
A useful technique to deal with this issue is to build the backend, integrate, but don’t build the user interface. The feature can be integrated and tested, but the UI is held back with the help of a keystone ( more info you may find in Martin Fowler’s blog ) and added only when the feature is completed, showing it to the users.
Software development teams use feature flags a lot because they deliver a ton of value. Engineers can integrate their changes more frequently. Feature flags, for example, the Koople tool, unlock capabilities like canary releasing, allowing teams to launch features safely.
As for the keystone flag, it is a pattern that helps to reduce the number of flag decision points for a feature by moving those decisions to the boundaries of the system.
Keystone Interface
The main idea behind the keystone interface is that you avoid long-lived feature branches by implementing a feature in a back-to-front way, exposing it in the user interface as the final step. This allows engineers to continuously merge their work into a shared integration branch without having that half-finished work exposed to any users. Once the feature is fully implemented, the software developer adds the interface – the keystone – which shows the feature to users.
Keystone Flag
Let’s see how the keystone interface can be used in event platforms where discount codes are needed. Discount is a simple concept to a consumer, however, it requires a lot of work behind the scenes. Software developers have to create internal user interfaces for creating and configuring discount codes, teach payment systems how to apply discounts, display discounts in orders, and so on. That “Add a discount code” UI is the keystone interface. Rather than leaving the keystone interface unimplemented, software developers can instead implement it but hide it behind a feature flag, with the flag off by default while the feature is still under development. This is a Keystone Flag – a feature flag protecting a keystone interface.
Keystone flags ensure that the half-finished feature isn’t exposed to our users, but internal users can access it for validation purposes – testing, showcasing, etc. Software developers can even do this testing in production if they want!
A keystone flag unlocks other opportunities beyond testing. Keystone flags also make releasing a feature safer in general. For example, imagine a scenario where the discount code functionality is implemented and tested, so it has been launched, turning on the feature for all users, but then developers discover a bug. It turns out that there is an issue with preventing the same discount code from being reused multiple times! Luckily, the UI to enter that discount code is still protected by a feature flag. Developers can very quickly disable the UI, preventing a massive loss in revenue.
If developers hadn’t used a flag, they’d have to perform an emergency rollback – with all the risks that entail. Any discount code functionality further within the system doesn’t need to be directly managed by a flag – we can have it sit latently in production, confident that it won’t be exercised until we’re ready to expose it via the keystone interface.
This is what makes keystone flagging such a valuable practice – it delivers all the safety benefits of feature flagging while minimizing the cruft that those same feature flags can add to your code.
