Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Running Argo CD in Production and What Changed from 2.x to 3.6: SSO, RBAC, Notifications, Metrics and Upgrades
Running Argo CD in production means keeping its own settings in Git, letting people in through SSO with least-privilege RBAC roles and CI with a time-limited token, disabling the admin account, adding notifications and an argocd_app_info alert, and staying within the last three minors. We apply accounts, RBAC and notifications from Git, see the 3.0 update, delete and logs changes, the metrics and the upgrade notes up to 3.6 with real output, and close the series.
Progressive Delivery with Argo Rollouts: Automated Canary Analysis with Prometheus Metrics
Argo Rollouts replaces the Deployment with a Rollout that opens a new version step by step and advances or rolls back by itself based on metrics read from Prometheus. We convert the Bookstore API to a Rollout, set up a canary with 25% and 50% steps in prod, and see with real output a good version going through, a version returning 30% errors aborted in 92 seconds, and Git brought back in line with a revert.
Secrets in GitOps: Sealed Secrets, SOPS and Keeping Secrets Out of Git Entirely
The safe ways to put a secret in Git are to encrypt it so that only the target cluster can open it (Sealed Secrets), to encrypt it with the team's key and decrypt it during manifest generation (SOPS and KSOPS), or to keep only a reference in Git (External Secrets Operator). With real output we take over an existing Secret, hit the strict scope, rehearse losing the key, add KSOPS to Argo CD and compare the three approaches.
Connecting CI to GitOps: Image Tag Promotion, Promoting Environments via Pull Requests and Image Updater
In GitOps, CI builds the image once, pushes it to a registry and writes which image should run into the config repo as a commit; Argo CD does the deploy. With real output we commit tag and digest to dev from a local CI script, promote to staging and prod via pull requests, hit a conflict between two pipelines writing the same file, watch Argo CD Image Updater drop a digest, and look at the Source Hydrator.
Many Environments, Many Apps: App of Apps, ApplicationSet Generators and AppProject
The way to manage many applications and environments in Argo CD is to apply, through an App of Apps root, an ApplicationSet that generates Applications from the folder layout, and to draw boundaries with AppProject. We generate Bookstore's api and web applications for dev, staging and prod from one ApplicationSet, update environments in order with RollingSync, and see with real output an AppProject rejecting a forbidden namespace and what preserveResourcesOnDeletion does.
Sync Waves and Hooks: Running the Migration Job Before the Deploy
In Argo CD, the way to run a migration Job before the deploy is to make it a hook and set the order with sync waves. With real output we see a plain Job failing on the second release with an immutable error, a PreSync hook running before the database in an empty environment and failing, the right order with a Sync hook and waves -1/0/1, a PostSync smoke test, SyncFail and PreDelete hooks, and how it fits expand-contract.
Sync, Health and Diff in Argo CD: Automated Sync, Prune, Self-Heal and Sync Options
In Argo CD, sync status says whether Git and the cluster match and health status says whether the objects in the cluster work; the two are independent. With real output we see a Synced but Degraded deploy, self-heal undoing a manual scale within a second while missing a manually added env variable, prune deleting a StatefulSet, and Prune=false, ignoreDifferences, RespectIgnoreDifferences and the other sync options.
Installing Argo CD and Its Architecture: Deploying Bookstore to a kind Cluster with Your First Application
Argo CD is a group of controllers running in the cluster that render manifests from a Git repo, compare them with live objects and apply them. We install Argo CD 3.6 into a kind cluster, map the repo-server, application-controller and other components, log in with the CLI, walk through the Application CRD and deploy Bookstore from Git, and we catch a commit that shows Synced yet changes nothing.
What Is GitOps? From Push-Based CD to Pull-Based Reconciliation, and When You Don't Need It
GitOps is a deploy model where the desired state lives declaratively in Git and an agent inside the cluster keeps pulling and applying it. We show with real output why a push-based pipeline misses drift, walk through the four OpenGitOps principles, a toy reconcile loop, repo layout decisions, Argo CD versus Flux, and when GitOps is not worth it.
From Helm 3 to Helm 4: What Changed, What Breaks and the Helm 3 EOL Timeline
Helm 4 manages Helm 3 charts and releases unchanged; what breaks are scripts, plugins and post-renderers, and Helm 3's security support ends on February 10, 2027. We run Helm 3.22 and Helm 4.3 side by side and look with real output at server-side apply latching, how mixing the two versions undoes server-side apply, flag and log changes, post-renderers becoming plugins, the experimental Chart v3 and a Helm 2 era chart, and finish with a migration checklist.
Dependencies, OCI Registries and Testing Charts: Chart.lock, helm push, lint, helm test and CI
Chart dependencies are declared with a range in Chart.yaml and pinned with Chart.lock; the chart is published to an OCI registry with helm package and helm push, but the registry does not stop you from pushing the same version again with different content. We add an optional Valkey subchart and global.imageRegistry to the Bookstore chart and look with real output at Helm 4's registry login and install-by-digest, kubeconform, helm test, chart-testing and a GitHub Actions workflow that runs them.
Managing Releases: install, upgrade --install, rollback, history, --wait and Migrations with Hooks
helm upgrade --install is the deploy command that leads to the same result on every run; a pre-upgrade hook runs the migration before the Deployment, but a rollback does not undo the database migration. We run Bookstore's EF Core migration bundle as a hook against SQL Server and look with real output at three real hook failures, Helm 4's kstatus-based --wait and --rollback-on-failure, recovering a release stuck in pending-upgrade, and server-side apply's field ownership conflicts.