A Kubernetes deployment should be easy to trace: what changed, who changed it, and why. That’s wh...A Kubernetes deployment should be easy to trace: what changed, who changed it, and why. That’s wh...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
A Kubernetes deployment should be easy to trace: what changed, who changed it, and why.
That’s what interests me about GitOps.
With GitOps, the desired state of your infrastructure and applications lives in Git. Changes go through commits and pull requests, while a controller such as Argo CD or Flux continuously reconciles the running environment with that desired state.
A typical workflow looks like this:
• Build and test the application through CI. • Push the Docker image to a registry. • Update the image version in the Git configuration. • Review and merge the change. • Let the GitOps controller reconcile the cluster.
The benefits go beyond automated deployments:
✅ A versioned history of configuration changes ✅ Reviewable changes before deployment ✅ Visibility into configuration drift ✅ A repeatable way to manage environments
One important detail: reverting a Git commit can restore an earlier configuration, but database migrations and changes to application data still need their own recovery plan.
For me, GitOps connects development and operations through a workflow both teams already understand: Git.
Are you using Argo CD, Flux, or CI-driven deployments for your Kubernetes workloads?
Post image
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started