As we all know, software developers can simplify the
development process by integrating their work as often as possible. It is also
known that frequent release into production helps a lot. But developers and
project stakeholders are reluctant to expose unfinished features to their
users. So what happens in this case? A useful method to solve this problem is
to create a back-end, integration, but not to create a user interface. The
feature can be integrated and tested, but the UI is kept with a cornerstone (more
on Martin Fowler's blog) and added only after the feature is complete, showing
it to users.
Software development teams often use feature flags because
they offer more value. Engineers can integrate your changes more often. Feature
flags, like the Koople tool, unlock features like canary release, allowing
teams to safely release features.
As for the trapezoid flag, this is a pattern that helps
reduce the number of flag acceptance points for a feature by moving those
decisions to the system boundaries.
keystone interface
The main idea behind the keystone interface is that it
avoids lengthy feature forks by implementing the feature from start to finish,
displaying it in the UI as the last step. This allows engineers to continuously
merge their work into a common integration branch without exposing the work in
progress to any users. Once a feature is fully implemented, the software
developer adds an interface, the cornerstone that displays the feature to
users.
cornerstone flag
Let's see how the Keystone interface can be used on event
platforms where discount codes are needed. The discount is a simple concept for
the 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, training payment systems to apply discounts, displaying
discounts on orders, and so on. This "Add Discount Code" UI is the
key interface. Instead of leaving the keystone interface unimplemented,
software developers can implement it but hide it behind a feature indicator,
with the indicator disabled by default while the feature is still under
development. This is the keystone flag: a characteristic flag that protects the
keystone interface.
The Keystone flags ensure that the feature in progress is
not available to our users, but can be accessed by internal users for review:
testing, demo, etc. Software developers can even test this in a production
environment if they want to!
The key flag unlocks other options besides challenges. Trapezoidal flags also make it safer to run the feature overall. For example, imagine a scenario where the discount code feature is implemented and tested, so it was released enabling the feature for all users, but then the developers discover a bug. Turns out there's a problem preventing you from reusing the same discount code multiple times! Fortunately, the user interface for entering this discount code is still protected by the function indicator. Developers can turn off the user interface very quickly, which will prevent a massive loss of revenue. If the developers did not use the flag, they would have to perform a crash rollback with all the risks that entails. Any discount code functionality outside of the system should not be directly controlled by the flag; we can make it idle in production, assuming it won't be used until we're ready to expose it via the keystone interface.
This is what makes keystone markup such a valuable practice:
it offers all the security benefits of function markup while minimizing the
hassle that the same function flags can add to your code.