{"id":909,"date":"2014-06-27T14:25:25","date_gmt":"2014-06-27T12:25:25","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=909"},"modified":"2024-03-15T15:18:49","modified_gmt":"2024-03-15T14:18:49","slug":"continuous-delivery","status":"publish","type":"post","link":"http:\/\/leanmagazine.net\/lean\/continuous-delivery\/","title":{"rendered":"Continuous Delivery \u2013 always ready to ship"},"content":{"rendered":"

\"\"<\/p>\n

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.<\/em><\/h4>\n

Ever since the company was founded in Aller\u00f8d, 25 km north of Copenhagen, Lars Kruse and his colleagues have been researchers in what they call \u201dThe Science of Continuous Delivery Maturity Models\u201d. Their results so far\u2014or as Lars Kruse prefers to put it: \u201da catalogue of observations\u201d\u2014 can be downloaded as a pdf booklet from their web site. The central doctrine is that every commit is a potential release candidate \u2013 you just have to test it to see if it is \u2013 or isn\u2019t.<\/p>\n

For companies who are new to Continuous Delivery (CoDe), a good place to start is where you often find companies on the lowest level:<\/p>\n

\"\"<\/a>
Lars Kruse is partner and co-founder of Praqma, a consultancy bureau specialized in services within optimization of software development processes and maintenance and development of Open Source tools for this purpose.<\/figcaption><\/figure>\n

\u201dIf one of the areas should be pointed out as a slow starter it must be the test and QA area,\u201d Lars Kruse says. \u201dIt 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.\u201d<\/p>\n

For the company that hasn\u2019t 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\u2019s legacy and already working.<\/p>\n

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.<\/p>\n

\u201dTest and QA may fall behind due to the fact that these are disciplines that developers traditionally have seen as being someone else\u2019s responsibility,\u201d says Lars Kruse. \u201dIt\u2019s all about embracing change: CoDe represents a shift in paradigm, and if you don\u2019t make the shift and start thinking differently, old habits simply take over. Soon this area grows to become a \u2018biggie\u2019 with a lot of complexity involved and tentacles infiltrating every other area. As\u00ad it gradually becomes a mess, projects tend to focus on other areas in order to show at least some CoDe progress. But it\u2019s not the right approach; the biggest pains should be addressed first!\u201d<\/p>\n

SCM large container<\/h2>\n

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.<\/p>\n

\u201dI 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 \u00ad to some extent \u00ad 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\u2019s not because we don\u2019t find them important, but rather that they are fairly complex and generally require a high maturity level anyway. We\u2019re trying to adapt to the doctrine that \u201ca good model is a simple model\u201d.<\/p>\n

Pains & low hanging fruits<\/h2>\n

Lars Kruse and his colleagues recommend that organisations approach CoDe based on two main principles:<\/p>\n

\u201dThe first principle is to address the biggest pains first,\u201d says Lars Kruse. \u201dWith this, we refer to an area that is starting to take the form of a road\u00adblock. If you don\u2019t address it, it will simply prevent you from moving forward.\u201d<\/p>\n

\u201dThe second principle is to pick low\u00ad hanging fruits, i.e. focus on areas where a desirable effect can be achieved with a very small effort,\u201d Lars Kruse continues. \u201dAs 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\u2019s like the Nike\u00ad approach \u2018Just Do It!\u2019.<\/p>\n

However, Lars Kruse points out that different businesses may have very different characteristics:<\/p>\n

\u201dA computer game company would very likely define pains and low\u00ad 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.\u201d
\n

\n

1\u20132\u20133: maturity!
\n\u2014three pieces of advice to anyone who wants to apply the Maturity model!<\/h2>\n

1. Be ambitious!<\/strong><\/p>\n

Most often we don\u2019t 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\u2019t do this, you\u2019ll be overtaken by your competitors. (I\u2019m trying to scare you, so you can get the adrenalin pumping\u00ad and grow some courage.)<\/p>\n

2. Be strategic!<\/strong><\/p>\n

The organisational change that you\u2019re 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\u2019s 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\u2019ll get the blame.)<\/p>\n

3. Be fast!<\/strong><\/p>\n

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 – \u00adwhich is fast. Hunt down manual processes and automate them. When you\u2019re 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.)
\n<\/div><\/p>\n

\"\"
\n

\n

Getting stuck<\/h2>\n

There are a some topics that tend to block the whole maturity process until they are addressed properly.<\/p>\n

Number 1:<\/strong> test and QA (see main text). A lot of companies give up on automating this.<\/p>\n

Number 2:<\/strong> 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, \u201cThe primary measure of progress is running code\u201d).<\/p>\n

The challenge is, that \u201crunning code\u201d 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. \u201cnot ready yet\u201d or \u201creleased\u201d, is absolutely imperative. I think companies get stuck here because it\u2019s usually an area which requires a lot of change\u2014either a different way of thinking about the current VCS or a switch to an entirely different one.<\/p>\n

Number 3:<\/strong> pre\u00adtested integrations. This is the concept that the project\u2019s integration branch can be written to only by an automated process, that only allows \u201crunning code\u201d 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\u2019s also a very important shift.<\/p>\n

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 hot\u00adfixes, fast tracks, or quick-\u00adand-\u00addirty solutions, there is only the DORITH approach (Do The Right Thing). In addition, this is also an area where the CoDe evolution typically halts.<\/div><\/p>\n","protected":false},"excerpt":{"rendered":"

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\u00f8d, 25 km north of Copenhagen, Lars Kruse and his colleagues have been researchers in what they […]<\/p>\n","protected":false},"author":32,"featured_media":920,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[69,5,83],"tags":[74,70,73,6,30,53,58],"_links":{"self":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/909"}],"collection":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=909"}],"version-history":[{"count":20,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/909\/revisions"}],"predecessor-version":[{"id":1150,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/909\/revisions\/1150"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/920"}],"wp:attachment":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=909"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=909"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=909"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}