CODE Stockholm Highlights: Data-driven DevOps and raising the Continuous Delivery game
CODE Stockholm is a one-day conference centered on Continuous Delivery and the DevOps movement. Both aspects were well covered through keynotes and two tracks of great talks.
All sessions and slides are available on the CODE site.
DevOps is transforming our industry, and data proves it
I’m a really big believer in data to back up theories and prove results, so it was pretty awesome to hear Nicole Forsgren talk about this in detail. The CEO of DORA (State of DevOps report) drove this point home in her two sessions, at the pre-conference meetup and as the first keynote of the conference.
By assessing a number of organisations, the DORA data shows that high performing organisations are focusing equally on all 3 aspects of DevOps:
- Technical practices (continuous delivery)
- Management practices (Lean principles)
- Culture of innovation and safety
Nicole also explained that the DORA research shows high performing organisations are not going through this journey blind: they are leveraging metrics to drive their DevOps culture. In her own words:
You can’t improve what you don’t measure. Without measurement, you’ll only know if it’s an epic fail or epic win.
Finally, she highlighted that DevOps transition for for high performers is not only about agility, it always goes hand-in-hand with stability. Data shows that such organisations have:
- 440x faster lead time
- 5x less chance of a change failing
- 96x faster recovery from downtime
Full slides: The Data Behind DevOps: Making the Case For AWESOME
DevOps cannot happen without investing in skills
ING is one of these high performing organisations, and Henk Holk talked about their 5+ year journey from a siloed structure to what they now call BizDevOps. He demonstrated that this transition was possible even in the strongly regulated banking sector. A big takeaway from the cultural shift at ING was that reengineering a whole organisation is inevitably limited by what people can do: embracing the fact that new skills and capabilities is key.
The result of this shift means that historically central roles progressively disappeared in ING:
- Product Owner responsibilities are now a shared concern of everybody in the organisation
- Software Engineers are now all full-stack and no longer siloed to only programming tasks
- IT Managers are becoming Coaches, focusing on enabling others rather than directing them
Agile is easy, the hard problem is re-engineering the enterprise while lacking skills & capabilities
Full slides: Enabling agility at scale for the heavily regulated
Bringing Continuous Delivery to the next level
Obviously CODE was a lot about Continuous Delivery and beyond the core principles, a couple of talks focused on the areas that remain left behind.
Treating the database changes like application changes
One of these is the database concerns in a CI/CD pipeline. Tom Austin (Redgate Software) noted that the database is very often the bottleneck in the pipeline: changes without database migration get through much faster than ones requiring manual intervention. This manual work is not only problematic for speed but for stability as well, as databases can drift if changes aren’t automated.
By considering database changes the same as application changes, Tom explained that it’s possible to apply the same CI/CD practices to them:
- Version control DB changes
- DB changes are made in dev and promoted to higher environments
- DB changes are automated through the pipeline (no more manual scripts)
- DB performance is monitored is all environments to pinpoint issues and correlate with changes
Full slides: Moving from application automation to true DevOps by including the database
The place of security in the CI/CD Pipeline
Another aspect that tend to be left behind is security. In the light of recent data-breaches and numerous vulnerabilities, Ryan Sheldrake (Sonatype) highlighted that most security issues are caused by dependencies. Without proper control or validation on third-party components, it’s impossible to prevent the introduction of vulnerabilities and to know if new vulnerabilities were discovered.
Some traditional approaches might prevent the download of a bad component, but this is not enough. As Ryan explained, introducing automated checks and policies in all steps of the pipeline can greatly help catch vulnerable components early and know when patching is needed. Making this information available to developers as early and clearly as possible is also key to success, with different kind of feedbacks:
- IDE plugins during development
- Clear and actionable information on builds rejecting vulnerabilities
- List of components in use in production, monitoring what needs patching
Full slides: DevSecOps - Security at the speed of Development
Thanks!
I would like to thank Praqma for having given me the opportunity to speak at CODE Stockholm (I gave a similar talk as at RebelCon: Increasing the visibility of distributed systems in production). It was a couple of days rich in learnings and conversations… and it was also a great excuse to visit beautiful Stockholm!