Hey there! I'm diving into GitOps and would love some insights from anyone who's made the switch. My team has been using traditional CI/CD pipelines with weekly production releases, but our leadership thinks GitOps would simplify things by setting the desired state in Git. My struggle lies in a fundamental question: how exactly do you establish the desired state initially?
Currently, our CI/CD process does the following:
- CI: Build, unit tests, security scans, and publishing artifacts.
- CD: Deploy to ephemeral environments, conduct integration tests, regression tests, and acceptance testing. This results in a validated git commit along with the artifacts ready for various stages.
The GitOps method I'm seeing generally involves:
- Standard CI processes (build, test, publish).
- No traditional CD.
- GitOps to deploy to a static environment.
- ArgoCD handles asynchronous deployments.
- ArgoCD notifications trigger Jenkins to run tests against the static environment, validating the desired state.
But this leads to my concern: how do you ensure your artifacts are a valid "desired state" without comprehensive tests beforehand? It feels like a backward approach—declaring a desired state before validating artifacts does not seem reliable.
I'm considering a hybrid method where:
1. Our current CI/CD pipeline creates validated artifacts.
2. A new GitOps stage in Jenkins updates manifests with validated references.
3. ArgoCD manages deployments from these validated manifests.
I'd love input on how others handle artifact validation in their GitOps setups:
- Do you run full test suites before or after ArgoCD deployments?
- Is there a better approach I might be overlooking?
- Has anyone managed to blend traditional CD validation with GitOps?
Any advice would be super appreciated! Thanks!
1 Answer
I see where you're coming from regarding the desired state. The concept of GitOps is that your deployments should reflect what’s in Git. A typical workflow would have your CI push artifacts to a repository. Image update automation then creates a pull request with updated deployment manifests. Once it's merged, CD automation deploys those manifests to the cluster, ensuring the deployed version matches what's in Git.
Thanks for your input! I get the GitOps model more now. But I'm still wondering, when do testing and validation fit into that flow? In our setup, comprehensive tests are run in CD pipelines before any deployment, but it sounds like with GitOps, tests happen post-deployment. How do teams deal with validation risk?