I’m admittedly a ‘weekend warrior’ when it comes to coding. That said, you don’t need to be a developer, or even know how to code a single line to understand this topic, participate in the process, or to delve into it on your own. A key benefit of cloud native architectures (i.e. infrastructure as code coupled with orchestration and containerization) is the pattern of updating components of an application, committing the changes to a git repository, in-turn triggering an automated rebuild/test of the definition and redeployment.

GitOps folds infrastructure as code into the DevOps pattern. With GitOps, we use a git backed repo to define both the service/application and infrastructure it requires. This is then extended with a CI/CD pattern to automate application lifecycle management. To breakdown CI/CD (Continuous Integration / Continuous Delivery/Deployment): CI is the task of automated building/rebuilding and testing on changes. CD is the task of deploying/redeploying after CI. There are tools that aim to accomplish both tasks, while others do just one. The difference between continuous deployment and continuous deployment is whether or not a service/application is automatically deployed on change. Continuous delivery denotes that human intervention is required before the service/application is re-deployed.

The first round of CI might run on a developer/tester local workstation, with additional stages running on shared infrastructure that closely replicate production. We could have a local git repo and K8s cluster on our workstation where we run test scripts before pushing changes to a centralized repo. We could have multiple centralized repos to represent various stages of additional testing. Once we test locally, we would push to the first centralized repo, merging with changes from others, and triggering additional testing.

This process of creating and integrating smaller changes through automation, with the ability to rapidly iterate over issues allows organizations to deliver new features with greater confidence, at greater speed, and with auditable/policy-driven configuration. Small changes are easier than largescale changes to test and troubleshoot. By maintaining the entire application and supporting infrastructure as a definition in code, we greatly increase the probability that an application behaves in production as it does in dev/test. You can checkout the CNCF landscape map of CI/CD platforms to gain insight into some of the tools available for these tasks.

Git logging (With proper use) allows us to easily rollback to a previous repo state. If we pass all automated tests and then encounter an issue in production, we can easily rollback the production git repo to the last-known-good commit. Which in turn, triggers a rebuild and redeploy of our last-known-good app/infrastructure state. Git repos also provides an audit trail for the who/when/how of changes, along with approver requirements. When we have a continuously running reconciler (e.g. Argo CD), an application/infrastructure definition is kept continuously in sync with desired/specified state.

To summarize, we start with an application architecture that allows us to define the application, operating system, and infrastructure as code. From there, we implement our code through a platform that orchestrates its lifecycle (e.g. Kubernetes). Finally, we add automation that recognizes changes we’ve made to our application/infrastructure definitions, rebuilds, tests, and redeploys (i.e. GitOps).