The Danish consulting company Praqma A/S has developed an appreciated maturity model for Continuous Delivery. Here, co-founder Lars Kruse shares some of his experience and reflections.
Ever since the company was founded in Allerød, 25 km north of Copenhagen, Lars Kruse and his colleagues have been researchers in what they call ”The Science of Continuous Delivery Maturity Models”. Their results so far—or as Lars Kruse prefers to put it: ”a catalogue of observations”— can be downloaded as a pdf booklet from their web site. The central doctrine is that every commit is a potential release candidate – you just have to test it to see if it is – or isn’t.
For companies who are new to Continuous Delivery (CoDe), a good place to start is where you often find companies on the lowest level:
”If one of the areas should be pointed out as a slow starter it must be the test and QA area,” Lars Kruse says. ”It is in this area that the quality of your code base is revealed. You need a lot of quality measure points in order to make decisions about promoting or not and it is also this area that produces the metrics that you would want to visualize.”
For the company that hasn’t included a CoDe perspective from the beginning, it can be quite a daunting task to make the decision where to start. For instance adding static code analysis to an existing project is very easy, but it will probably reveal a lot of issues. To prioritize cleaning up the code may be hard, since it’s legacy and already working.
Hence, the visibility that is created from doing the analysis is categorized as noise. Unit testing and automating functional testing require that the application in question is designed to be testable. Access to test environments and consistent test data are also needed. Being too ambitious in this field may have an impact on the system architecture, the deployment process and the access to resources. If test and QA is treated more as an afterthought than an actual strategic point of focus, it has a negative impact on the CoDe maturity.
”Test and QA may fall behind due to the fact that these are disciplines that developers traditionally have seen as being someone else’s responsibility,” says Lars Kruse. ”It’s all about embracing change: CoDe represents a shift in paradigm, and if you don’t make the shift and start thinking differently, old habits simply take over. Soon this area grows to become a ‘biggie’ with a lot of complexity involved and tentacles infiltrating every other area. As it gradually becomes a mess, projects tend to focus on other areas in order to show at least some CoDe progress. But it’s not the right approach; the biggest pains should be addressed first!”
SCM large container
In the CoDe model, Software Configuration Management is primarily defined as different levels of version control. Still there are other aspects of SCM that affect the level of maturity.
”I dare say that all the disciplines that are traditionally seen as belonging to the domain of Software Configuration Management affect CoDe. SCM is quite a large container for a lot of related disciplines. CoDe can to some extent be seen as offering a flow-oriented view of many of the same disciplines. In the model, we have distributed some of the obvious ones such as deployment, dependency management, maintenance of test data, and server provisioning into some of the other areas. The reason for this is basically that they are kind of cross area disciplines and having them all in the SCM area would simply clutter it. But other obvious SCM related areas such as task management, system architecture, and release strategies are not mentioned explicitly in the model. It’s not because we don’t find them important, but rather that they are fairly complex and generally require a high maturity level anyway. We’re trying to adapt to the doctrine that “a good model is a simple model”.
Pains & low hanging fruits
Lars Kruse and his colleagues recommend that organisations approach CoDe based on two main principles:
”The first principle is to address the biggest pains first,” says Lars Kruse. ”With this, we refer to an area that is starting to take the form of a roadblock. If you don’t address it, it will simply prevent you from moving forward.”
”The second principle is to pick low hanging fruits, i.e. focus on areas where a desirable effect can be achieved with a very small effort,” Lars Kruse continues. ”As an example, introducing a new tool is typically easier than replacing an existing one. Consider you are in a situation where you are stuck in an old bespoke VCS and you are not doing any unit testing. In this situation, introducing a unit test framework would be almost free. It’s like the Nike approach ‘Just Do It!’.
However, Lars Kruse points out that different businesses may have very different characteristics:
”A computer game company would very likely define pains and low hanging fruits differently from a large industrial manufacturer that happens to have embedded software in some of its product lines. Accordingly, they would implement CoDe via different paths.”
1–2–3: maturity!
—three pieces of advice to anyone who wants to apply the Maturity model!
1. Be ambitious!
Most often we don’t get to reach everything we dreamt of, so to score high, our ambitions will have to be even higher. Think of CoDe not so much as a competitive advantage but rather as a competitive necessity. If you don’t do this, you’ll be overtaken by your competitors. (I’m trying to scare you, so you can get the adrenalin pumping and grow some courage.)
2. Be strategic!
The organisational change that you’re looking at is probably a bigger challenge than all the processes and tools in your tools stack; after all they are just tools! Use an approach that allows you to change the wheel on the bus while it’s rolling. A lot of small changes in the right direction, an evolution rather than a revolution. (Remember: when something goes wrong, people start looking for reasons and if you are driving the change you’ll get the blame.)
3. Be fast!
Remember: in the pipeline, speed should be prioritized! Think of it this way; In CoDe there are no hot fixes, only plain vanilla fixes. Your commit should be able to travel through the entire pipeline in the time that represents the minimum acceptable time it takes to apply a hotfix – which is fast. Hunt down manual processes and automate them. When you’re done, you should find some more and automate them too. (CoDe is closely related to an agile approach, which is born out of lean principles. Hence, CoDe should be lean.)
Getting stuck
There are a some topics that tend to block the whole maturity process until they are addressed properly.
Number 1: test and QA (see main text). A lot of companies give up on automating this.
Number 2: failure to implement a VCS and a branching strategy that actually supports the agile way of thinking (see the seventh principle in the Agile Manifesto, “The primary measure of progress is running code”).
The challenge is, that “running code” is not necessarily ready to ship, and in CoDe you need to be able to operate with a sometimes fairly complex notion of promotions. A branching strategy that supports more than just two possible states, i.e. “not ready yet” or “released”, is absolutely imperative. I think companies get stuck here because it’s usually an area which requires a lot of change—either a different way of thinking about the current VCS or a switch to an entirely different one.
Number 3: pretested integrations. This is the concept that the project’s integration branch can be written to only by an automated process, that only allows “running code” to enter and forever keep the integration branch pristine. It sounds like a dream, and it is indeed one of the more advanced maturity signs. But it’s also a very important shift.
Hence, this where it shows if the company actually did adopt the paradigm shift of quality enforcement rather than policy enforcement. From this point on there are no more hotfixes, fast tracks, or quick-and-dirty solutions, there is only the DORITH approach (Do The Right Thing). In addition, this is also an area where the CoDe evolution typically halts.
