DevOps

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. ...

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. ...

GitOps changed how I think about deployments. Instead of running commands against a cluster, I push to Git and watch the cluster converge to the desired state. It sounds simple, but the implications are profound. ArgoCD is my tool of choice for GitOps. Let me show you why, and how to get started. Why GitOps? The Philosophy First Before diving into ArgoCD, let’s understand why GitOps matters. Traditional deployment: Developer → kubectl apply → Cluster The problem: What is deployed? You have to query the cluster. Configuration drift happens silently. Rollbacks are manual and error-prone. There’s no audit trail beyond “someone ran kubectl.” ...