TicketOps, DevOps, GitOps, SecOps - what are they? Have we come to the point when these acronyms do not make any sense?
At least, a few of them do make sense. We are going to look at GitOps today - a very fresh way of deploying our software.
Essentially, that's how you reliably and repeatably take a piece of software into a particular environment while collaborating with other people working along. But how that look in practice?
In practice, you have a recipe to make GitOps happen:
If you take Kubernetes, you would have to store a Kubernetes YAML manifest in the Git repo, and have a tool that would repeatedly pull that manifest to check whether it has something to deploy onto the Kubernetes.
If you take Docker Swarm, you would have to store a docker-compose.yaml in the Git repo and have a tool that would pull from the repo and apply that compose file onto Swarm.
This is exactly as simple as keeping the desired state of the application deployment in the Git repo. As we update that deployment state in the Git repo, it updates in a particular environment.
That gives us the ability to collaborate with our peers on that manifest using Git workflows - pull requests to change the version of the image in the cluster or add an extra LoadBalancer. It's the way for software engineers to collaborate on their deployments using the good old instruments they know - Git, PRs, comments, history, rollbacks, and so on. With this approach, there is no need to go deep on deploying the software to an environment, since the GitOps tool will do that for you. Not everyone needs that, but almost everyone needs a way to deploy their build artifacts in a safe, repeatable, and reliable way.
We've been working tirelessly to give everyone that ability to deliver software in a reasonably simple manner. I think we nailed it with our latest 2.9+ releases. In the next part of this series, we'll go over Portainer's take on GitOps.