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.

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 .