Entering GitOps 2.0 with Codefresh and ArgoCD

In our previous article, we explained the vision behind GitOps 2.0 and the features we expect to be covered by GitOps 2.0 tools.

In this article, we will see how the new Codefresh GitOps dashboard is the first step towards this vision and more specifically in the area of observability and traceability.

Getting visibility into deployments

Deploying a new release into production is an important milestone for all project stakeholders. The developers write the code, the operators deploy the new artifact and product owners can finally mark a feature as “shipped”.

Current deployment tools however do not give the same attention to the needs of all team members that take part in a release. Most deployment tools today fall under the following categories:

1. Really low-level tools that are mostly useful to developers. They are full of build logs, Git hashes, and deployments events that mean nothing to product owners or business analysts.
2. High-level “deployment” tools that are actually a fancy UI layer on top of a low-level tool exposing only a minimal amount of information. These tools treat a deployment as a black box (as the actual deployment process is handled behind the scenes from another entity) and never give enough information on what went wrong if a deployment happened.

The reason behind this dichotomy is probably that each role needs access to different information. This might be true in a historical context but goes against the ideas and principles of DevOps (bringing all team members together).

Ideally, deploying a release should be so easy to perform/monitor/rollback that any team member can handle a deployment event and still have access to all critical information such as which Git commit was deployed and what new features are now available.

Deployment value comes from features and not Git hashes

In the GitOps 2.0 article, we outlined the gap that exists today between the low-level deployment information (i.e. the Git hash) and the value it brings after a deployment (i.e the actual features).

Product value is not measured in Git hashes, but instead in the number and significance of new features that are deployed to production. New features are typically recorded in an issue management system (e.g. JIRA) and have their own lifecycle according to what the organization desires.

As a first step towards the vision of GitOps, we have decided to address this information gap and solve the observability problem by combining these two kinds of information (git hashes and features) in a single cohesive view.

You can now use the new Codefresh dashboard and correlate extra information on top of a single Git hash.

The new Codefresh GitOps dashboard

Our new GitOps dashboard provides a single pane where instead of looking for simple Git hashes, you can now see:

• The feature(s) implemented by this Git hash (i.e. JIRA issues)
• The Pull Request that was created for this feature
• The committer of the feature
• The timeline of deployment for this feature and if the deployment was successful or not
• The pipeline(s) that were used for building the container image and deploying it
• The Kubernetes images that were affected
• The Kubernetes services/deployments that were affected

With our new GitOps 2.0 dashboard, we are addressing the visibility and observability problems that plague existing GitOps tools.

Now you can finally get an overview of GitOps deployments in the context of features instead of just Git hashes. In addition, you can rollback to a specific feature (and/or pull request) in addition to a Git hash.

Using the dashboard you will be able to answer questions such as:

• Which feature was implemented by Pull Request 432?
• When was JIRA issue 5612 deployed in our QA environment?
• Is JIRA issue 2356 deployed in production now?
• Can we rollback the staging environment to just before JIRA-issue 2167 was shipped?
• Which pipelines were used for handling Pull Request number 156?
• Who pushed to our production (by committing into Git) last Friday afternoon?
• What JIRA features entered our staging environment this morning?
• What container images were rebuilt as a result of merging Pull Request 475?
• Which Kubernetes services were affected by JIRA issue 5923?

These are just a few examples of the capabilities you gain with the new GitOps 2.0 dashboard in its initial release. We have several other enhancements on our roadmap and we also welcome any additional feedback that you have regarding the structure and functionality of the dashboard.

Argo CD Integration

Instead of re-inventing the wheel, the new GitOps dashboard is powered by Argo CD, the popular deployment solution that can manage Kubernetes applications using a pull mechanism.

To take advantage of the Argo integration, you simply install our agent in the same namespace as the Argo services. Installation is as simple as running a single command via the Codefresh CLI:

Once the agent is installed, Codefresh has two-way communication with Argo CD via its API. For example, Codefresh will automatically mark an application as out-of-sync if the cluster configuration no longer matches the Git repository, which holds the manifests file that describes the application.

With the Argo CD integration in place, you can also define GitOps application right inside the Codefresh UI, with the same options available to Argo CD

It is important to notice that at all times you can still use the Argo CD user interface in addition to the Codefresh UI.

CI/CD pipelines with Codefresh

With the Integration of Codefresh and Argo, you now have a full CI/CD solution at your disposal.
Argo CD is a great deployment tool on its own, but it can only handle the last step in a pipeline created for GitOps deployment (the sync part).

A full deployment platform also needs the ability to compile applications, run unit tests, perform security scans, etc. These capabilities are out of scope for Argo, but are perfectly possible with Codefresh.

On the other hand, Codefresh already has strong CD foundations, but they are based on the push-model (deploying Helm packages on a cluster). With the addition of Argo, our customers can now create GitOps pipelines if they prefer.

This means that one can now create complete GitOps pipelines that are not possible by using Argo on its own.

For example, a very popular pattern for deployments is to have pre-sync and post-sync steps in a deployment pipeline.

A possible scenario for a pre-sync step is to send a message to your monitoring solution that a deployment is about to take place. This way your monitor solution can place a “marker” on your time-based metrics to evaluate the health of the deployment (and possibly rollback automatically if the metrics are not healthy).

A possible scenario for a post-sync step is to perform smoke testing on the deployment that was just synced. Codefresh has great support for both unit and integration tests both of which require the capabilities of a full CI/CD platform.

As a more advanced scenario, Codefresh can actually orchestrate a single deployment pipeline that follows the GitOps paradigm as it is possible to automatically perform a Git commit inside a pipeline (as well as a replacement on the manifests).

The example above is a single pipeline that:

1. Checks out the source code of the application
2. Builds a Docker image
3. Records the information for the current pull request what JIRA issue is solved
4. Creates a commit on the second git repository that holds only the Kubernetes manifests.

Of course, a pipeline like this can be easily enriched with additional steps for testing, linting, security scanning, etc.

It is important to note that the existing CD capabilities of Codefresh (and all dashboards such as the Helm promotion one) are still available to companies that wish to continue using them even if you don’t want to follow the GitOps paradigm.

Getting started with GitOps 2.0

With the marriage between Argo and Codefresh, you get a full CI/CD platform that combines the ideas of GitOps, along with an extensible model of pipeline building that can match any possible deployment scenario.

To get started you can now open a free account with Codefresh and then follow our documentation guide for GitOps deployments.