Keystone Pattern

Reading the Continuous Delivery book recently has got me thinking a lot about ways to achieve continuous integration while still adding new features. The book suggested Branch By Abstraction as a way to avoid stepping on each other’s toes. It also mentioned the Keystone pattern.

When creating an arch the keystone is the large stone at the top. It is the last stone you put in. It locks the others in place.

The real problem the Keystone pattern addresses is the following: I want to add a feature and it’s large so it is going to take several commits. I want to keep my software in a state where after each of these commits, I could potentially ship this software to my customers. What I want to avoid is my customer seeing some half-finished feature. I could create a branch for this feature, but I want to avoid that so that I can do continuous integration.

The key to understanding the Keystone Pattern is looking at a feature from the point of view of the user. Most features involve some sort of UI element. A checkbox, a button, perhaps some whole new panel or display. That is the keystone. Just as if we were building an arch, we put the Keystone in last.

What this allows us to do is to make a bunch of commits on behind the scenes code that the user doesn’t even see. This lets us integrate that code. We can test it, make sure it builds, etc. Then when we are sure that it is ready, we simply add the UI element, the keystone which exposes it to the user.

Need Help?

Would you like to have confidence that your code is always ready to ship? Want help setting up continuous integration for your organization? Let’s schedule a call to talk about it .

2 Comments on “Keystone Pattern

  1. This pattern is the basis of many LabVIEW features over the decades. Channel wires and malleable VIs are just two of the most recent features that were available in earlier versions of LabVIEW than they were actually released in, but the UI element (existence in palettes, existence in popup menus) that let a user use those features was hidden. An advantage of the keystone pattern not mentioned in the blog post is that if you have a way (like a config token) to unhide that key UI element, then you can enable select customers play with your new feature in real world situations before you release it to the world. This allows you to find UX issues that would otherwise be hard to identify before they become a locked-in part of your software.

    • Thanks for pointing that out. I knew that VIMs and Channel wires were available in earlier versions, but it didn’t occur to me as an implementation of this pattern until you pointed it out.

Leave a Reply

Your email address will not be published. Required fields are marked *

*