At Codefresh, we are always happy to see companies and organizations as they adopt Argo CD and get all the benefits of GitOps. But as they grow we see a common pattern:
- An organization adopts Argo CD and one or more teams are really excited with the automation and visibility features it brings along with it
- Argo CD is then introduced to other teams expecting the same productivity gains as the initial team(s)
- For some strange reason, Argo CD migration is not going well, and major blockers are found. Developers express concerns about how Argo CD affects them and their daily routine.
It is at this point that organizations come to Codefresh and ask how we can help them scale out the Argo CD (and sometimes Argo Rollouts) initiative in the organization. After talking with them about the blockers, we almost always find the same root cause.
- The initial team that adopted Argo CD used it for external software that gets installed on a Kubernetes cluster but is not actually developed internally. The initial team uses Argo CD for installing things such as cert-manager, nginx, sealed-secrets, Prometheus and other third-party applications that are wholly owned by Kubernetes engineers.
- The teams that had issues with Argo CD adoption tried to use Argo CD for internal applications that were developed in-house.
This is a very important distinction to understand for any company that wants to adopt Argo CD. Installing off-the-shelf applications and installing internally developed applications is a completely different story. This is also where the usual Argo CD questions come in, such as how to organize GitOps repositories and how to promote between environments
Argo CD does not understand the relationship between applications
Argo CD is great for installing off-the-shelf software but is missing several important requirements for internal applications. Let’s see an actual example to understand why this happens. Here is a typical Argo CD dashboard for an internal application called “accounts”
In this scenario, the application is deployed in 3 different “environments” called qa, prod and staging. The operations team has chosen a special naming convention <application>-<environment> to denote this.
The key point here is that the concept of environments is just a naming convention. You only know that this is the same application because, as a human, you look at the application name and understand what is going on. But for Argo CD, these are 3 completely random applications with no special connection between them. Argo CD does NOT understand that these are three instances of the same application.
This means that there is no intelligence on how to understand what a promotion means and how to move this single application from one environment to another. The result? The teams that try to adopt Argo CD for their own applications realize that they do not get promotion out of the box and need to start implementing ad-hoc solutions. These solutions are almost always not what the developers expect and this means friction between the organization developers and the operators that try to introduce Argo CD.
Making Argo CD smarter with application Products
We need a way to make Argo CD smarter and “teach it” that the applications on a cluster are not a flat list, but instead have relationships between them. The way we do that is by introducing a new concept called “Product”. Here is the same view as before but in the Codefresh Environment dashboard.
You should be able to spot the differences right away. This is a feature-rich screen that includes much more information, such as
- The version of each application
- Who did the last promotion
- When the promotion happened
- What was the feature that went into the promotion
- Any currently open promotion requests
All this information is not part of the vanilla Argo CD.
The most important feature, however, is that we do not have 3 random applications anymore. Codefresh understands that all of them are the “accounts” product (shown in the title of each card). This single accounts product is now deployed in 3 different environments (qa, staging, production) as before.
This means that Codefresh knows that these 3 Argo CD applications are not completely random, but are instead the same application in 3 different instances.
We can take advantage of this fact in several use cases, with the most obvious one being product promotion.
Promoting Argo CD applications with drag-and-drop
Because Codefresh is smart enough to understand that the “accounts” product currently exists in all 3 environments along with a different version, when it comes to promotion you can simply drag and drop a release to the next environment 🙂
Here, we are dragging the account product from staging and dropping it into production. Codefresh understands that this is the same application, and it auto-calculates what needs to happen in order for the promotion to take place.
As we follow GitOps by the book, Codefresh proposes the commit that will promote the application to the next environment.
In this simple demo, we only change the application version. Codefresh supports much more advanced scenarios, including bringing along configuration changes and we’ll share more about customized diffing for Argo CD applications in a future post.
You can also see that you can automatically create a pull request for the promotion (which we recommend for production environments) or commit directly to the branch (useful for non-production environments).
This makes application promotion a straightforward process. It doesn’t get any simpler than this!
We also need to be clear that this drag-n-drop process can, of course, be disabled without losing the other benefits if you only prefer to promote automatically and not in the Codefresh UI. And, of course, you can define extra approvals or decide precisely what will happen when a promotion takes place (such as running smoke tests or other security checks
Grouping applications into products is just adding an annotation
You might think defining a “product” would be a super complex process proprietary to Codefresh and adopting products in your Argo CD instance will lock you in the Codefresh platform. This could not be further from the truth. We designed the product concept only to require a Kubernetes annotation.
You can use the default codefresh.io/product annotation or any other annotation you would like. This will be especially useful to organizations that already have marked Argo CD applications with their own annotations for introducing a “product-like” entity.
Other use cases for products
Argo CD Products are available today in the new Codefresh environment dashboard. Apart from the promotion use case, we are also handling another use case that will be very useful to organizations that have adopted microservices.
Usually, a microservice-enabled application has several individual workloads that form a single entity. An example could be a “billing” application which itself contains 3 microservices called “orders,” “users,” and “payment gateway.”
Annotating these individual microservices as a single product will allow Codefresh to handle them in a uniform manner. As a quick example, application promotion will happen for all 3 microservices at the same time, and application rollbacks will also happen in a similar fashion.
We also have a lot in store when it comes to connecting Argo CD products with Codefresh environments. Stay tuned!
Get started today by creating an account and we would love to hear from you!
