We've just launched a new survey asking How Continuous is Your DevOps? - you can check it out here (and you can win big prizes!). So it's got a pretty catchy title, huh? But what do we actually mean? Continuous Delivery and DevOps have been virtually synonymous for quite some time even though this makes us want to tear our hair out; DevOps is about so much more than a bit of automated integration and testing, although we'd be the first to agree that always having software in a releaseable state is a jolly good thing. On our DevOps Foundation Course we spend some time talking about Continuous Integration, Delivery and Deployment and the relationship and evolution between the three states, but there are five more Continuouses we regularly address in DevOps Transformations. Let's look at all eight a bit more closely and through a DevOps lense:
1) Continuous Funding
So most organisations go through annual budget cycles; onerous, horrible things that take months and eventually pop out a number normally much lower than the original one anybody thought of. Also - they have to happen before the start of the financial year. So sometimes you'll be spending budgets that could easily have been set over twelve months previously. But aren't we continually (see what I did there?) being told that everything changes and that the pace of change is accelerating? Aren't we all getting Agile because we know our customers change their minds at the drop of a hat? We're developing and delivering in iterations so people can get their hands on what they really want faster - but we're still budgeting in a waterfall manner.
In Frederic Laloux's book, Reinventing Organisations, he describes the ongoing evolution of organisations away from hierarchical, command and control structure towards a holocratic, everyone's a sensor in an ecosystem approach. The latter type of organisation value constant (guess what that's a synonym for) sensing for what's needed rather than trying to predict and control it. They work with no or radically simplified budgets and don't track variance. Instead they look for workable solutions and fast iterations; they don't look for 'perfect' answers and they don't set targets. Much can be learned from this - there is a hybrid approach we observe often, where a 'bucket' of budget is set for an initiative and can be drawn down incrementally as needed.
2) Continuous Integration (CI)
We don't see many companies not performing Continuous Integration these days - the time where one developer was the sole inputter to an application is long gone and composable, composite applications are prevalent now requiring the integration of code branches - frequently. CI might be older than you think, though, as a described principle; if I said it's been around since 1991 it may or may not surprise you. CI was originally developed to support XP (eXtreme Programming) but is no longer so tightly linked - many (most?) organisations today practice CI using build server like Jenkins and Bamboo without practising XP. A question for you though - if your organisation is developing applications composed of open source artifacts, how can you discover and manage the risk around those parts? Perhaps you want to check out Sonatype's Lifecycle solution for managing your software supply chain.
3) Continuous Delivery (CD)
Next up we have Continuous Delivery (CD) which needs CI to function and aims to always have software in a releasable or deployable state. CD builds on the unit tests completed in CI and automates additional user acceptance tests (and more) and packages the software so that if the team are ready to deploy it, they can. Benefits of CD include:
- Accelerated Time to Market
- Building the Right Product
- Improved Productivity and Efficiency
- Reliable Releases
- Improved Product Quality
- Improved Customer Satisfaction
You can read more about our customer Hiscox's award winning Continuous Delivery project here.
4) Continuous Testing
Organisations doing CI/CD will already have automated parts of their testing as described above - but is this Continuous Testing? As organisations embrace Agile and become more iterative in their approach to software development, delivery and deployment, traditional methods of testing, which rely heavily on manual testing and automated GUI tests that require frequent updating, cannot keep pace. Even after more automation is added to the existing test process, managers still lack adequate insight into the level of risk associated with an application at any given point in time. Understanding these risks is critical for making the rapid go/no go decisions involved in Continuous Delivery processes and the tests developed must be appropriate for the levels of risk the business is willing to take. This is true DevOps - bringing the business in early and often and understanding and supporting the functional and non-functional requirements.
This is 'shifting left': testing begins early and is executed continuously so that application risks are exposed soon after they are introduced. This reduces the time and effort that needs to be spent finding and fixing defects. As a result, it is possible to increase the speed and frequency at which quality software (software that meets expectations for an acceptable level of risk) is delivered, as well as decrease technical debt.
5) Continuous Deployment (Should we call this CDep?)
Continuous Deployment automates the last step in the deployment pipeline to the live or production environment and means that every change is automatically deployed to production - these is no manual step or 'button push' here. Continuous deployment is the goal of most companies that are not constrained by regulatory or other requirements. There are business cases in which IT must wait for a feature to go live, making continuous deployment impractical. While application feature toggles solve many of those cases, they don’t work in every case - and neither does every organisation have the ability to feature toggle today in any case. You can use scripts to automate the deployment but over time you will probably find these become complex and unreliable and may want to consider using a deployment/application release automation tool. This discipline allows us to achieve two specific DevOps goals:
- Release/Deploy on-demand
- Make the process 'like breathing' - nice, huh?
6) Continuous Measurement
The 'M' in the DevOps acronym CALMS stands for metrics, and we spend a lot of time with organisations defining the 'metrics that matter' and building KPI trees. The biggest challenge we see is defining metrics in IT that really matter to the business and the common ambition is to be able to measure what we call 'from Ideation to Realisation'; that is the cost of a feature from the moment it is conceived as an idea AND the value it returns to the business when it is running in live.
DevOps demands that The Three Ways be embraced and practised. The Second Way is all about amplifying feedback loops and is critical to Continuous Measurement. The Third Way, experimentation and learning, takes Continuous Measurement to completion.
7) Continuous Learning
We established in Section 6 that learning and experimentation are critical to DevOps success as the Third Way, but many organisations we work with are so busy with fire-fighting/unplanned work or are resource constrained to the point where the thought of stopping to learn or try something new seems an impossibility. Google's 20% time is well-documented - but how practical is it to give all of your engineers (all of your staff?) a day a week to work on something of their choosing? If the time is allocated to working on learning/experimenting with something that has a direct impact on the team's goals, then much more so. But make sure these goals are clearly articulated and shared.
Experimentation time can also be co-ordinated as groups conduct hackathons or run virtual or physical simulations of hypothetic scenarios. Gamification is becoming increasingly popular - initially branding and marketing have embraced this approach for making interactions more fun, increasingly organisations are looking for ways to (check out this webinar from Gartner). We like reading this story about Facebook's release engineering practices and how they use karma points in development.
Broadly speaking, there are 3 main areas of gamification:
- Design behaviours (Ideation/requirements gathering, DevOps/Agile simulations, Karma Points)
- Develop skills (Hackathons, Chaos Monkey)
- Solve problems (prizes for failure, Bug Bounties)
8) Continuous Improvement
Lots of people ask us what DevOps is and it's widely recognised that it's hard to pin down a definition. The movement has largely resisted documenting some kind of manifesto a la Agile. We tend to boil it down to "making better software faster and more safely" but there are an enormous amount of activities around improvement that we split into three areas:
When we run our DevOps LiftOff Workshops there is often an output which is a big sigh of relief as the organisation workshopping realises that they are already on a DevOps journey and they haven't committed some enormous oversight. Some organisations we work with have had issues launching DevOps initiatives, usually related to development automating things without security and operations collaborating (now that's not very DevOps is it?) and they don't really want to use the term anymore. All of this is fine, if DevOps is nothing more than a label or synonym for Continuous Improvement that's all good. All we're trying to do is make life on earth fantastic.