Track features, not code
Updated: Jul 8, 2020
When we're talking to Product Owners, we always talk about user stories or features: they're never interested in which microservice or UI test has been delivered to support that feature, so why do all our delivery tools track code not features? Of course, JIRA looks at features; indeed, it's how we drive development and all the Agile ceremonies. But as soon as we get into the mechanics of source control, promotion of code and environments we drop down to code artefacts. Take a look at the tools, everything looks at it from the Dev or Ops perspective.
Let's turn that around: what it everything (not just JIRA) but our release tools, our quality gates, and even our development approach was entirely focussed on features rather than code artefacts? We (and I mean the big "we" of Devs, QAs, Ops, Release, Support, Product Owners, stakeholders, sponsors, even Users) would now all be looking at, talking about and planning the product in the same way: a shared experience.
To take an example, release teams look at release notes to understand what bits of code or database updates that release contains and the features they support. This is time-consuming and error-prone and it tends to result in a "fix forward" culture of getting the new release in and then fixing problems as they occur. Now, if we track features rather than code, we should be able to see inside our running OpenShift environments (rather than at a release document) to understand which features are available for promotion. We would also ensure that they all ran together before we were allowed to promote them. We would see how long those features had been waiting to be promoted to the next environment (so we could start to question why delays occur), and we would, with a single click, promote those features (as a proven and safe release) into the next environment.
What about developers: how do we get them thinking about features rather than code changes? The source control and task management tools are already there for us, we just need to link them. We do this, for example, by adding pre-commit hooks to Git so that developers have to link the (e.g. Jira) card they are working on to each code change. This allows us to draw changes together into a set describing the feature which we can then track through our OpenShift environments.
QAs also link their tests to feature cards. They also need to plan which kinds of tests are appropriate for which environments - we don't run the same tests everywhere, not least because we tend to use Docker containers so the code isn't changing as we promote it. This gets us thinking about quality gates and environments: we've already covered moving a set of features that has been proven to work together, now we need to think about specific tests that must be met before the features are suitable to be promoted to the next environment.
Release teams now have an easier job: they know what's running where, are confident that each environment has the necessary resources it requires for a set of features - that configuration is linked to the features we're building - and that those features all work together to an agreed quality standard. What we see is that they are much more prepared to release code into higher environments, will do so more frequently, cutting the size (and hence risk) of each release as they do so.
With our new feature view, it becomes easier to see how Blue/Green deployment works: we flip users between two production environments (Live and Staging) so that they experience zero down-time as we flip to the new version. We promote our feature set to Staging, run our quality gate tests to ensure it all works together, and then flip the two environments. If our monitoring shows a problem, we just flip back.
Whether this all seems obvious to you, or entirely alien, the one thing we need is a UI to tie it all together. We've built it and, at first sight, most people think they're just looking at a Jira or Trello board. It's not: it's actually drawn from the live pods running on OpenShift, showing which features are available where. The blue cards represent those which are available to promote to the next environment. We have quality gates between each environment so you can only promote stories when everything has passed the tests and, crucially, works with the other stories or features that are available in this environment.
You can see here that stories have been promoted into the Test environment meaning that the tests have to be run before the stories can be promoted to the Performance environment. However, those on the Performance environment have been run successfully so that they can be promoted to the Security environment by clicking the "Promote" button. Note that this moves all the stories from Performance to Security in one go and can only be done by a user with the necessary security privileges unless the step is configured to be fully automated, i.e. the code is automatically promoted as soon as the quality gate is achieved.
So, what do you think? Does it really make sense to track code when what we all really care about is features? In a future blog post, we'll take you through a couple of other core concepts including Product Streams (how you manage branches in the source code) and Reversion (how you can back out to a particular version of the environment and stories).