We’re excited to announce the first set of official Codefresh steps for Octopus Deploy. This provides another way to streamline your processes by integrating your Codefresh builds with deployments in Octopus Deploy. In this post, we walk you through the process of creating a release and deploying it to an Octopus environment through Codefresh Pipelines.

Two of the most popular guides we’ve written are the GitOps promotion guide and the ApplicationSet guide. Used together, they explain an end-to-end solution for organizing your GitOps applications and promoting them between different environments, while keeping things DRY by using application sets. Both of these guides use Kustomize. We offered some hints for Helm users, but this is a dedicated guide for Helm applications.

One of Argo CD’s standout features is its powerful user interface (UI) that shows the live status of all applications and the respective Kubernetes resources. Both developers and operators can quickly understand the status of their deployments by looking at the UI and drilling down into all the different views of Argo CD applications. Some teams even use the Argo CD UI as a generic Kubernetes dashboard and management interface (especially after the addition of the web-based terminal feature).

Welcome to our quick start guide, designed to help you get the most from Codefresh. Whether you want to use the CI portion to build and test your applications or explore the GitOps feature powered by Argo CD, this is the place to start. We’ll walk you through setting up runtimes for non-production and testing purposes and provide sample code to ensure you have everything you need to get started. You can use the code provided as a model if you need to deploy in a production manner.

Argo CD is the most popular GitOps tool for deploying applications to Kubernetes clusters. Many teams that move their applications to Kubernetes choose Argo CD for its powerful sync engine and intuitive dashboard. Argo CD is also fully open source, which means teams can freely install it on their private clouds, behind-the-firewall data centers, or even in air-gapped environments without any licensing restrictions.

Accidentally deleting an application is bad, but accidentally deleting all of them is a lot worse. In this post, I show you how to avoid issues like the following: Argo CD finalizers is a built-in Argo CD feature that confuses many new users and can even result in accidental deletion if you’re not careful. If you see a resource managed by Argo CD that was supposed to be deleted but isn’t, then you can almost certainly blame a finalizer.

Teams adopting GitOps often ask how to use secrets with Argo CD. The official Argo CD page about secrets is unopinionated by design and simply lists a set of projects that can help you with secrets. We’ve seen several approaches to secret management. These include sealed secrets, the Argo CD Vault plugin, and the External Secret Operator. In this post, we showcase the External Secret Operator and Hashicorp Vault and focus on 2 important aspects.

Kubernetes at the edge has become extremely popular with retail companies like Chik-Fil-A and Starbucks, leading the way as famous examples to the more exotic US Air Force deploying Kubernetes on F-16s. At Codefresh we’ve seen and helped implement every kind of edge deployment from clusters in retail stores, mobile clusters in vehicles, air-gapped clusters for telecoms, and lots more.

In our big guide for Kubernetes deployments, we explained the benefits of using dynamic environments for testing. The general idea is that each developer gets a preview environment instead of having a fixed number of testing/QA environments. The environment gets created on the fly when you open a pull request. Typically, it gets destroyed when you merge the pull request (or after a specific amount of time).

Have you ever found yourself wrestling with the complexities of managing ArgoCD applications across multiple environments? Are you constantly juggling naming conventions and struggling to correlate applications representing the same microservice or product? If you’ve been deep in the trenches of GitOps, you’ve likely encountered these challenges firsthand.