Argo: The Safeguard to the Demise of DevOps
Argo was born out of the idea that DevOps isn’t a role, it’s a process. It’s one we all participate in, like it or not. And since the rising tide of opinions seem to hint at an early demise for DevOps as a discipline, the Itential DevOps team set out to equip their developers with an operational toolbox to make their lives a little easier. Using the guiding principles of continuous integration, continuous deployment, and continuous delivery, we converged on a unified process and tool that could be scaled indefinitely to safeguard the demise of DevOps at Itential.
What is Argo?
Argo, at its core, is a set of bash scripts that are loaded into a container runtime and enabled at a global level within the container. Encased in these bash scripts is the logic that defines how Itential conducts end-to-end continuous integration and continuous delivery (CI/CD).
- deploy – inclusive of Semantic Versioning, Semantic branch parsing, Git tagging, Jira ticket updating, Release Notes generation and updating, and registry publishing
- docker_deploy – image building, deploying to registry, semantic version tagging, git tagging (non-master builds), and clean-up of old non-master tagged images in the registry
- kubernetes_deploy – staging cluster deploys for pull requests, staging clean up on pull request merge to master deploys, and Kubernetes service generation (GKE/GCP only)
In order to create a CI/CD (continuous integration/continuous delivery) tool that stores all the logic and duties of a DevOps team, we had to make some hard decisions about our core CI/CD methodology. We chose Semantic Versioning with Itential Git Flow.
Itential Git Flow reduces the complexity of deploying software by simplifying the branch strategy to a single “master” branch that represents the overall health and quality of the application.
Semantic Versioning is a well-defined protocol for how changes are documented to user facing projects and interfaces.
The decision to choose both those methods in tandem came down to how we view our software development lifecycle in conjunction with a few core tenants of modern software development. For our team, we were able to draw consensus on five main points:
- Master should always be ready to deploy
- Software going into master should always be well-understood, well-tested, and overly communicated
- Changes to software should be compartmentalized and risk-averse
- APIs are contracts with our users and teammates
- Changes to APIs should be guided by the principles of Semantic Versioning
With so many tools available for CI/CD processes, why should I choose Argo? Two main reasons: unification and extendibility.
Unification – Argo differs from most of its competitors in that it houses the entire CI/CD flow. For example, Versioning is handled in the same place that applications are deployed to Kubernetes. Other tools of Argo’s ilk either focus on one aspect of the CI/CD flow specifically or they neglect to properly address versioning. The purpose of publishing an opinionated CI/CD flow is to take the guesswork out of the process.
Extendibility – Argo is open sourced, so it’s easy to contour to your team’s needs — just fork the repository and add an executable script in the src/scripts directory.
The Future of Argo
The burgeoning theme of software development paradigms in a networking environment is one we contended with daily. As the world continues to be eaten by software, we can’t help but feel like Argo and the DevOps problem is something akin to a metaphor for the broader market. Something that will, perhaps, one day lead to true software-defined networking.
If you are looking to safeguard the demise of DevOps on your team, check out the GitLab Repo for Argo.