CI/CD

Every deployment is a risk. The question isn’t whether something will go wrong — it’s how much damage it will cause when it does. Traditional Kubernetes deployments are all-or-nothing. You push a new version, and within seconds, 100% of your traffic hits the new code. If there’s a bug, everyone sees it. If the service crashes, all users are affected. Progressive delivery changes this equation. Instead of deploying to everyone at once, you gradually shift traffic to the new version, validating at each step. If something goes wrong, only a fraction of users are affected. ...

You can’t secure what you don’t understand. And with container images, understanding means knowing exactly what’s inside — every package, every library, every potential vulnerability. Most teams treat their container images as black boxes. They pull a base image, add their code, and push it to production. But that base image? It contains hundreds of packages you didn’t explicitly choose. Any of them could have known vulnerabilities. Trivy makes the invisible visible. It’s an open-source vulnerability scanner that tells you exactly what’s in your images and what risks they carry. ...

Version numbers shouldn’t be a decision. They should be a consequence of the changes you made. Semantic versioning (semver) has clear rules: MAJOR: Breaking changes MINOR: New features, backwards compatible PATCH: Bug fixes, backwards compatible But manually deciding “is this a minor or patch?” is error-prone and inconsistent. Let’s automate it. The Core Idea: Conventional Commits The magic ingredient is conventional commits — a standardized commit message format that tells tooling what kind of change you made. ...

I run GitLab self-hosted. Not because it’s trendy, but because I want to own my CI/CD pipeline. No vendor can change pricing, deprecate features, or access my code without my knowledge. This is sovereignty applied to CI/CD. And GitLab makes it practical. Let me show you how to build a complete pipeline: from code commit to running in Kubernetes. Why Self-Hosted GitLab? Before we dive into pipelines, the “why” matters: Data sovereignty: Your code, your builds, your artifacts stay on your infrastructure No usage limits: Unlimited CI minutes, unlimited storage, unlimited users Network locality: Builds run close to your clusters, faster artifact transfers Customization: Configure runners exactly how you need them Air-gap capable: Works in offline environments The trade-off is operational overhead. You maintain GitLab. For me, that’s worth it. ...