How could we seamlessly combine the best of GitOps with powerful deployment orchestration from Octopus?
That’s the challenge we took on during three days of ideation in Auckland earlier this year.
We filled whiteboards with drawings and sticky notes, building out a story map of what the ideal solution could look like.
Integrating with Argo CD was surfacing regularly in our customer interviews and we started getting comments about it on our roadmap. Fast forward a few months and we’ve just shipped the Early Access version of Argo CD in Octopus to Cloud customers.
Here’s a behind-the-scenes look at how we turned user feedback and sticky notes into real capabilities you can use today.
Going from discovery to making design decisions
The expansive story map made it clear that we’d have to break the solution into smaller iterations. We wanted to ship valuable capabilities and start getting feedback as quickly as possible.
The first shippable release would include:
- A step to update container images
- A step to create and update manifests from templates
- Committing directly to Git or creating pull requests
- Connecting to Argo CD instances by installing a gateway
- Seeing application health on the live status page
Connecting with the Argo CD community at KubeCon London
We used the opportunity at KubeCon to get feedback on early-stage prototypes, connect with folks in the Argo CD community, and get more data about questions like:
- How do Argo CD users feel about using annotations to map applications to Octopus projects, environments, and tenants?
- How much would users still rely on the Argo CD UI or did they expect us to bring those capabilities into Octopus?
Key design decisions
Here are a few of the design decisions we made and the rationale behind them:
Simplifying step setup
Since Argo CD steps require a few prerequisites, we made that process as linear as possible.
Conditional empty states on the deployment preview will tell you exactly what you need to configure for the step to run successfully.
Since Argo CD instances aren’t deployment targets, we’ve added a deployment preview to show you which applications will be deployed with a particular step.
Making gateway installation easy
It was important for us to allow users to register existing Argo CD instances in Octopus.
To communicate with Argo, Octopus requires a gateway installed on the cluster. We opted to use a similar multi-step wizard to the Kubernetes agent to simplify gateway installation.
You need to provide a few details about your Argo CD instance, and then you get a custom-generated Helm command to install the gateway.
Generating annotations
Instead of using the Octopus UI to tell us which applications to deploy, we decided to use a Git-centric approach. We now help you create annotations that map your Argo CD applications to Octopus projects, environments, and tenants.
This approach also introduced some design challenges, since open source tools like Argo CD and Helm can support a broad range of use cases. We’re still fine-tuning our approach here to balance flexibility and simplicity.
If you’re interested in sharing your use case with us, schedule a 30-minute chat.
Live status & observability
When we built Kubernetes Live Object Status, we used Argo CD statuses to simplify future integrations between the tools.
To provide application developers with observability across multiple applications, we’re showing the status of your Argo apps on the live status page and we’ll be adding child object statuses soon.
We’re delivering this observability capability iteratively and plan to expand it to events and logs in the future.
More capabilities coming soon
We’re not done yet.
Our team is planning to release more capabilities in the next few months and we’d love your feedback on the direction we’re taking.
How to try Argo CD in Octopus
These new capabilities are currently available in Early Access to all Cloud customers.
Add an Argo CD step to your process and start combining the best of GitOps with the power of Octopus.
Happy deployments!
Tags:
