Editor’s note: This guest blog post was contributed by Jan Hoppe, Java developer at Heidelberger Druckmaschinen AG.
Like almost everything else in our digital economy, building a modern printing press requires a lot of software. I know this first-hand from working as a JAVA developer – DevOps Lead at Heidelberger Druckmaschinen AG, also known simply as Heidelberg, the world’s largest manufacturer of offset printing presses. Increasingly, software drives our engineering systems and underpins nearly all of our products and services, including our latest generation of smart connected digital presses.
Not surprisingly, Heidelberg’s software operation is impressively large and complex. We have more than a dozen development teams and run about 180 continuous delivery pipelines, all integrated into one unified system. Of course, the problem with a system of our size is sometimes you can’t easily see what’s happening across the whole landscape, especially issues and bottlenecks that could be stalling critical value streams.
And this is where CloudBees DevOptics is starting to play a valuable role by helping us pinpoint hang-ups in the value flow and boosting the productivity and speed of our development teams. Most of our teams, by the way, have adopted continuous delivery methods using the CloudBees Core to automate our software development environment.
The first time I saw CloudBees DevOptics was about a year and a half ago, shortly after DevOps World|Jenkins World 2017, while I was attending some follow-up meetings in Hamburg. Watching a demonstration of the CloudBees DevOptics value stream, I was struck by the clear “big picture” it provided of the overall infrastructure. You could literally visualize the complexity. I have since used DevOptics to automatically map out the value stream for our entire system at Heidelberg.
The visibility we get from DevOptics is enabling us to spot issues faster and move more confidently to fix them. Maybe an API has been changed and it breaks a build. Or a process is hanging somewhere. Now we can immediately find the source of the problem and go fix it. And we can track all of these changes over time. Getting a big picture of the various dependencies between projects also helps us decide which components and paths we need to build to bring the system up to date.
Using DevOptics, we are gathering some good performance metrics that are helping us understand team productivity and the efficiency of our development operation. One measure called Deployment Frequency (DF) – that is, how often we deploy code to production – is giving us a good sense of the overall speed and efficiency of our software delivery lifecycle.
Another metric I’m tracking is Mean Time to Recovery (MTTR), or how fast we can fix problems. This number is interesting because if it’s increasing, then something is going in the wrong direction! It’s worth noting that before DevOptics, measuring these metrics – and others such as Mean Lead Time (MLT) and Change Failure Rate (CFR) – would have been virtually impossible.
To be fair, we are only just getting started with DevOptics at Heidelberg and it will take time to exploit its full potential. But I am confident that the greater visibility we’re getting from DevOptics will translate into faster, higher-quality software development – and that is a huge competitive advantage for any company. Keeping our developers as productive as possible will allow them to innovate more – and innovate faster. And that’s always a good thing for Heidelberg.