Continuous delivery should be treated as an agile project as it is about automating your deployment. You have to speed up in small steps and gain trust by doing small deliveries and solve problems fast, said Kim van Wilgen, CIO at Klaverblad. She spoke at SwanseaCon 2016 about continuous delivery. InfoQ is covering this conference with Q&As, summaries, and articles.
Initially Klaverblad, a mid-sized Dutch insurance company, was using mainframes and programming was done in Cobol. It became harder to change the software to ensure that it kept serving the business needs; the decision was taken to start all over and do a green field reboot.
Since new development of the IT systems is so huge, you have to do it the right way, said van Wilgen. But due to the size of the company we have to realize IT with a smaller budget, which calls for innovation in the way that software is developed, she continued. They decided to base their software development approach on Agile, DevOps, continuous delivery, and microservices.
Klaverblad decided to apply agile because they want to deliver value fast to their customers and get early feedback from reality; they want to deploy daily. Manual delivery however is error prone and hard to do. With over 200 microservices that are individually deployed, automation is needed. You can’t check 200 components manually, said van Wilgen. This is why we need continuous delivery and DevOps, van Wilgen clarified.
There are good reasons to strive for continuous delivery said van Wilgen. When you are delivering more often your testing can become lighter; the fast feedback in production helps you to find and fix problems right away. Continuous delivery enables fast recovery, if there’s an incident then you can limit the damage. You are able to make smaller changes which are easier to do. Also you don’t need instructions for the users of your software, since the IT changes are small and intuitive. Team motivation goes up knowing that users are using their software quickly after they created it. Finally the quality of the software can be increased through full automation of your tests and quality metrics and by using best practices.
Van Wilgen explained that to become agile at Klaverblad a change in culture was needed. This change could be done through introducing new practices, in turn the practices could be driven by tools. They decided to start by providing new tools for their developers and testers, but the results weren’t as expected. Tests turned out to be incomplete, there was hardly any branching, and insufficient monitoring and logging. They needed a different approach.
If you start with continuous delivery you should see it as an agile project to automate your deployment, advised van Wilgen. Make a backlog with steps to improve capabilities, prioritize, define minimum viable products, and set stages where you deliver parts of the solution.
Klaverblad uses the Continuous Delivery Maturity Model to manage their continuous delivery journey:
This Maturity Model aims to give structure and understanding to some of the key aspects you need to consider when adopting Continuous Delivery in your organization.
[The Continuous Delivery Maturity Model] includes adopting specific tools, principles, methods and practices that we have organized into five key categories: Culture & Organization, Design & Architecture, Build & Deploy, Test & Versification and Information & Reporting. Structuring Continuous Delivery implementation into these categories that follows a natural maturity progression will give you a solid base for a fast transformation with sustainable results.
As the CIO, van Wilgen acts as product owner for the continuous delivery project- she decides what needs to be done. There are people from teams throughout the organization working in this project; it is a team effort, said van Wilgen.
Continuous delivery is about collaboration, working together. You have to learn a lot to implement continuous delivery, so make sure you have time to do this. Van Wilgen explained what they do to make the organization a learning organization: they turned their teams into DevOps teams, and have guilds, hackathons and knowledge events where people can learn form each other.
Doing continuous deployment and deploy immediately after acceptance with microservices was doable, said van Wilgen, but if you need to postpone delivery of a microservice it became more difficult. This happens for instance when a feature gets rejected or if you want to postpone due to marketing of the product. The changes applied to some of the microservices will be delivered while delivery of changes to other microservices is postponed. In such cases you are delivering a configuration which is different from the one that has been tested in the different stages of your build pipeline.
You can’t test all possible combinations with all of the versions of the microservices, there are too many. Van Wilgen explained their current approach: do instant delivery when you can so directly deliver a feature when it is ready, and make a feature branch or toggle for things that might have to be delivered later. It turns out that most features can be delivered immediately; van Wilgen explained how they "cherry pick" features that need a different solution and then decide how to do integration testing for them.
Is the business ready for continuous delivery? Mostly not, argued van Wilgen; they want it but didn’t think about it. They expect extensive fall-back plans for situations when things go wrong. They want to see manual user acceptance testing. They ask for user instructions, documentation and communication about the changes. This becomes a major slowdown for daily delivery so you need to manage these stakeholder requests. You can explain that you don’t need fall-back plans; with continuous delivery you can fix the problem and do a new delivery quickly when things go wrong, said van Wilgen. Also you have to tell them that you don’t need user instructions for small changes.
You have to speed up in small steps and gain trust by doing small deliveries and solve problems fast, argued van Wilgen. Make it a priority to talk about continuous delivery. Show the quick wins, and emphasize how valuable it is to go to production fast.
You are nothing in continuous delivery without your quality gates, said van Wilgen. Klaverblad does code reviews and unit testing, regression tests and integration testing and automates and manual user acceptance testing. They prioritize tests and decide what to do now and what they can do later. Tests that will find major bugs are run early, and some smoke testing is done to quickly find regression bugs. These small tests will provide fast feedback to the developer. When these tests are green then in progressive steps more extensive and exhaustive tests are run to fully inspect the changes. Van Wilgen stated that the product owner works with testers, gives input and approves the automated user acceptance tests.
Continuous delivery is about technology and people, said van Wilgen. IT and business should work together to prioritize and deliver consistent sets of features.
