In last week’s post, I wrote about how Anzu Services help engineering teams bridge the gap between the cloud and their codebase by leveraging code generation and the provider ecosystem to connect resources to services within seconds.
This week, I’ll focus on Anzu Dev Environments: Developing software locally involves using a mix of local and managed resources. Previously, Anzu already managed hosted resources, and starting today, Anzu handles local resources just as well.
This is a huge step in creating a streamlined workflow, helping teams go from prototype to production.
Let’s dive into how Anzu Dev Environments work!
The Motivation
Most teams use shell scripts, Docker Compose files, and other ways to configure their local resources, while also depending on remote resources managed manually or using IaC. This divide makes it harder for teams to connect the two parts: How do identifiers, access keys, secrets, and other values move from resource management to local services?
Keeping the two platforms separate also makes it harder to judge what’s running, and see the differences between local development and production.
Anzu wants to help teams move faster, happier, and that includes every stage from developing locally, to deploying and managing software in production.
Local Resources
With the latest release, Anzu introduced local resources. Providers can simply tag a resource as local, which has implications for the deployment workflow down the road. Most notably, having local resources defined on a branch prevents you from creating deploy requests in the dashboard.
The simple reason why we had to add this limitation is that your deployments run on Anzu’s managed infrastructure, far away from your local machine. When you want to deploy a container on your laptop, however, we need to run the deployment right on that machine, not in the cloud.
With this in mind, let’s explore the new workflow for creating and using Anzu Dev Environments.
CLI-first local development workflow
Moving to your development machine, the Anzu CLI takes care of provisioning, updating, and tearing down your Dev Environment. Let’s check out the newly-added CLI commands.
anzu dev
Running anzu dev will provision a new Dev Environment if not created previously, running the deployment entirely on your machine. This is the case for all resources, not just local ones.
For the time being, each member may only have one Dev Environment for a given project.
anzu svc run <service> <command…>
After deploying a Dev Environment, you may want to run a service locally, as opposed to deploying a local container. This means that, instead of adding the service token to a resource, you need to pass the token to the local process. This is exactly what anzu svc run takes care of.
Examples:
# Spin up Dev Environment
anzu dev
# Prerequisite: Create service named api
anzu svc run api pnpm start
anzu svc run api go run .
# Destroy Dev Environment
anzu dev down
anzu dev down
Runs teardown deployment, deleting all resources associated with the Dev Environment.
Anzu Dev Environments are available starting today, we’d love to get your feedback on the experience!