This was the first time I did two presentations at the same conference. Since I’ve already done the one about pipelines a lot of times already, I really only had to prepare for the second one, so it was nice.
The venue was an old industrial hall and it was pretty cold, next time I’ll bring a sweater…
Pipeline Patterns & Anti-patterns
Automated pipelines have become an integral part of our daily workflow. As the pipelines become increasingly important, the demands placed on them rise proportionally.
As with many things, a great pipeline operates seamlessly in the background, while a poorly designed one becomes a constant irritation.
Are you publishing your artefacts every time the pipeline runs, running all steps in a sequence, or installing all the tools every time a new build starts?
In this talk, I will address these antipatterns and more I have encountered during my work as a consultant, explaining why I consider them such and what you should do instead.
After listening to this talk, you will better understand what makes a pipeline great and concrete things you can do to improve it and shorten the feedback loop.
Scratch that: working with minimal container images
Container images can be described as an operating system in a bottle. They run under the host Linux kernel, but often contain numerous libraries, utilities, and programs alongside the software you put in them.
As an example, the “stable” Debian base image (as of 2025-09-29) contains 111 packages, takes up slightly over 50 MiB of space and lists 21 vulnerabilities.
The “latest” Alpine base image, on the other hand, only has 20 packages, takes up less than 4 MiB of space and lists 2 vulnerabilities.
In this talk, I’ll discuss what makes up a container image, a bit about how they work, and the benefits and drawbacks of these two images (and others, such as Red Hat’s UBI images). I’ll also talk about scratch images—what they are, when you might use them, and some caveats.