On the 7th of December we were present at the second edition of the Continuous Delivery Conference held in Bussum, the Netherlands. Phrases like “Software is eating the world!” and “Continuous Delivery is no longer a Nice-to-have but a MUST-have in today’s economy of software”, were the opening statements of a day that would bring a whole bunch of interesting topics. They provided insight into the speaker’s companies’ efforts towards Continuous Delivery.
It was a great chance to see how much interest companies and individuals from all sectors are (finally) putting on this topic. Continuous Delivery might have been around for a long time already, but only now this concept seems to gain stronger than ever traction in the mind-set and roadmaps of technology-supported businesses.
Ongoing process in the whole range
The keynote speakers covered the whole range from managers to developers that have been or are being part of the transformation towards Continuous Delivery (CD) in their organization. From CD leaders like Spotify, to front-runners in the Netherlands like ING and Bol.com they all presented not only the gains and the positive aspects that CD has brought for them, but also touched upon the big challenges in changing of mentality and technical constraints that can come up in the “journey”. It’s exposed as a journey, because the transformation is an ongoing process that requires patience and a steady effort to change mind-sets, process optimization, automation of as much as possible, and use of right tooling among other aspects.
Interesting, yet sometimes underestimated aspects of CD were discussed with very concrete examples and analyses.
Regarding continuous communication, the different types of conflicts (intrapersonal, interpersonal, intragroup and intergroup) set the starting point to present different resolution techniques. Avoiding being on the extreme and worse part of the spectrum of techniques, and compromising being the right (but not obvious) foundation and definitive first step to greater collaboration in complex working environments. Of all the keynote talks, this one spoke to me the most given that the people factor represents in my opinion the biggest challenge in CD transformations.
Trunk based development
Another interesting talk showed how trunk based development in a real life project would help achieve continuous integration by providing a way of working that, even though it could sound risky and even scary, could actually enforce and facilitate Continuous Integration practices like integrating once a day by every team member. On the other hand, feature branching was presented as an approach that often won’t help Continuous Integration, because of branch integration overhead. A combination of these two can be achieved though, but it would require discipline on common tasks like code reviews to avoid having stale branches that are harder to integrate as time passes.
Breakout sessions at the conference
Apart from 4 keynote speakers, there were 8 breakout sessions that were categorized in: What works and what doesn’t, CD Mind Set, CD implementation, Improving Collaboration and
Research & Development. The sessions I chose to attend were: Making Continuous Delivery work for you (Songkick), Transitioning development of a large software product (ING), Speed up software delivery using Docker based Continuous Delivery pipelines (Cloudbees) and Make customers even more happy with continuous delivery at scale (bol.com). The
reason for such a choice was to have a balance between getting insight on CD adoption strategies by the presenting companies and some technical update when it comes to
implementing delivery pipelines, in this case environment provisioning with Docker and Jenkins Workflows.
Continuous testing and test automation
Test automation has proven to be an essential part of advancing to Continuous Delivery, and it was stressed throughout this conference by the experts presenting. On the main stage, 2 out of 4 keynote speakers had continuous testing and test automation as their main topic. The first one of these was called Quality@Speed and Diego Lo Giudice from Forrester stressed that Continuous Delivery is not only about delivering fast, but also with higher quality. Shift-left principle and test automation are key to build quality in, and will be essential for any software project to provide better definitions of done and to deliver value to business sooner and more often. Diego closed with 7 suggested steps to achieve CD:
- Automate Environment Management
- Integrate Continuously
- Automate testing with APIs
- Make data driven release decisions
- Reduce size of releases
- Eliminate hand-offs and wait time
Number 3 for me represents an interesting point that I think test automation will be moving to when it comes to End-to-End testing, given how easy it is to break tests that rely on UI for interaction with the SUT (System Under Test).
Mobile applications and apps
To close the day, Kristian Karl, Test Manager at Spotify, shared challenges that they have been going through regarding testing the front-end of their mobile applications and how the nature of their apps also makes (at least for now) it preferable to test most of their features against production. He presented common automated tasks that contribute to CD with built-in quality and that they broadly use at Spotify like: Code style checking, archiving artefacts, dynamic code analysis and deployments.
He also presented some figures where he would compare testing at different levels (GUI, API, Unit Test) and about having around 70% of the business logic possible to test mainly via the GUI, only 5% of code coverage and a duration of hours compared to seconds for unit tests. He presented this to raise awareness on how the testing efforts are spent for some software projects.
Lessons learned for Continuous Delivery
Attending the conference was a valuable opportunity to see how efforts are being put in several aspects of CD by companies in different sectors, and a chance to get an update on where is the industry struggling and what are the lessons learned over the last few years. One thing is for sure: the journey to Continuous Delivery remains difficult when it comes to adoption of new ways. Spending effort on acquiring the technical skills needed and at to change mind-sets are necessities that take time. However, it is a process that is worth going through to accelerate value throughput for technology supported businesses.
Other relevant DevOps content
- BLOG: Red Hat – OpenShift Day-2 Ops from the trenches
- REPORT: 2018 State of DevOps Report – DevOps Research Assessment
- OFFER: DORA – DevOps Research and Assessment
- BLOG: Observability in OpenShift with Prometheus
- WHITE PAPER: The Digital‐Native Enterprise – The Red Hat and Devoteam Success Formula
- BLOG: Shared continuous delivery toolchain, the silver bullet?
- NEWS: Atlassian Gold Solution Partnership for Devoteam
- INFO: Our CALMS approach towards DevOps
- CASE STUDY: Improving the CIO delivery cycle at Liberty Global
- BLOG: Monitoring to reduce Mean Time To Recovery (MTTR)
- EBOOK: API Strategy and Architecture
- EBOOK: DevOps Perspectives
- OFFER: DevOps and Culture
- OFFER: Continuous Delivery
- CASE STUDY: Same meat, different gravy
- BLOG: Become a high performing organization with DevOps as business enabler