Argo CD and Server-Side Apply: Who Owns Which Field
Server-side apply moves the merge into the API server and replaces the last-applied annotation with field ownership. What that actually changes in Argo CD.
blog/tag
#gitops
Argo CD et le server-side apply : qui possède quel champ
Le server-side apply déplace la fusion dans l'API server et remplace l'annotation last-applied par des propriétaires de champs. Ce que ça change dans Argo CD.
Sync options Argo CD : ce que chaque option change vraiment
Les sync options d'Argo CD passées une à une : ce que chacune change à la commande appliquée, et laquelle se pose sur l'Application ou sur la ressource.
Argo CD Sync Options: What Each One Actually Changes
Argo CD sync options one by one: what each changes in the command actually run, and which ones belong on the Application versus on the resource.
Atlantis : deux verrous différents, pas un seul
Atlantis verrouille un répertoire Terraform contre deux PR concurrentes. Ce verrou n'a rien à voir avec le lock d'état Terraform, un mécanisme indépendant.
Atlantis: Two Different Locks, Not One
Atlantis locks a Terraform directory against two concurrent PRs. That lock has nothing to do with Terraform's own state lock, an independent mechanism.
Backstage : le vrai risque, c'est le catalogue périmé
Backstage centralise la découverte des services, mais sa valeur dépend de catalog-info.yaml. Sans propriétaire clair, le catalogue diverge de la réalité.
Backstage: The Real Risk Is a Stale Catalog, Not the Tool
Backstage centralizes service discovery, but its value depends on how fresh catalog-info.yaml stays. Without a clear owner, the catalog silently drifts from reality.
Environnements de preview éphémères par pull request
Des environnements éphémères par pull request, créés et détruits automatiquement, résolvent un vrai problème de revue. Ce que ça coûte en isolation, et le piège du nettoyage qui ne se fait jamais.
Ephemeral Preview Environments Per Pull Request
A full ephemeral environment per PR, provisioned and torn down automatically, solves a real review problem. What it costs in isolation, and the cleanup that never fires.
GitOps à l'échelle : ApplicationSets, le piège du tenant
Gérer un Application ArgoCD par service tient à dix équipes. À cent, ApplicationSets automatise la génération, mais déplace le vrai problème d'isolation.
GitOps at Scale: ApplicationSets, the Tenant Trap
Managing one ArgoCD Application per service holds up for ten teams. At a hundred, ApplicationSets automate generation, but shift the real isolation problem.
Crossplane vs Terraform: Who Fixes Drift First
Terraform catches drift at the next plan, whenever someone remembers to run it. Crossplane fixes it continuously, using the same loop that already manages pods.
Crossplane ou Terraform : qui corrige la dérive en premier
Terraform détecte la dérive au prochain plan, quand quelqu'un pense à l'exécuter. Crossplane la corrige en continu, via le même mécanisme qui gère déjà les pods.
Déploiement progressif multi-cluster : au-delà du pod
Un canary réussi sur un cluster ne garantit rien sur les autres régions. Comment orchestrer un rollout progressif entre clusters, vague par vague.
Multi-Cluster Progressive Rollout, Beyond the Pod
A successful canary on one cluster guarantees nothing about the others. How to orchestrate a progressive rollout across clusters, wave by wave.
ArgoCD ou Flux : comment choisir son outil GitOps
ArgoCD et Flux résolvent le même problème par deux modèles différents : UI centralisée contre contrôleurs composables. Le vrai critère de choix.
ArgoCD vs Flux: Choosing a GitOps Tool
ArgoCD and Flux solve the same problem with two different models: a centralized UI versus a set of composable controllers. The criterion that actually decides.
GitOps with ArgoCD: Declarative Deployment Explained
How ArgoCD continuously reconciles cluster state with Git, the difference between push and pull deployment, and what drift actually reveals.
GitOps avec ArgoCD : le déploiement déclaratif expliqué
Comment ArgoCD réconcilie en continu l'état du cluster avec Git, la différence entre push et pull deployment, et ce que la dérive (drift) révèle vraiment.
kubectl apply : le merge que personne ne regarde vraiment
kubectl apply n'écrase pas un objet, il le fusionne. Ce mécanisme invisible explique pourquoi un kubectl edit manuel disparaît silencieusement au prochain déploiement.
kubectl apply: The Merge Nobody Actually Looks At
kubectl apply doesn't overwrite an object, it merges it. That invisible mechanism explains why a manual kubectl edit silently vanishes on the next deploy.
Database Migrations in the CI/CD Pipeline
How to sequence a database migration job ahead of a rollout, the expand/contract pattern for zero-downtime changes, and why rollback is often a myth.
Migrations de base de données dans le pipeline CI/CD
Comment ordonnancer les migrations de schéma avant un rollout, le pattern expand/contract pour rester compatible, et pourquoi le rollback est souvent un mythe.
kubectl rollout undo: How Kubernetes Rollbacks Work
How Deployment revisions map to ReplicaSets, what kubectl rollout undo actually restores, why GitOps prefers a Git revert, and the gotchas around rollbacks.
kubectl rollout undo : comment fonctionnent les rollbacks
Comment les révisions d'un Deployment correspondent aux ReplicaSets, ce que kubectl rollout undo restaure vraiment, et pourquoi GitOps préfère un revert Git.