Adopting Garden
This page contains a high-level overview of the steps required to adopt Garden. The configuration snippets are just for demonstration purposes to help you understand how Garden grows with your stack.
Step 1 — Pick your plugins
The first thing you do when adopting Garden is to pick the plugins you want to use. Plugins are configured via the providers field in the project level configuration. Plugins also define module types that we'll get to below.
The provider configuration will look something like this, depending on the plugins you're using (we're omitting some details here):
Each plugin has a dedicated section in our documentation that explains how it works and how you can get started using it.
We recommend starting simple with a single plugin and adding more as needed. In most cases you'll want to start with either the kubernetes or local-kubernetes plugins and build from there.
Below you'll find a brief overview of our main plugins. Once you know what you need, we suggest heading to the "Configure Plugin" guide for your plugin of choice.
Local Kubernetes
This plugin is great for kicking the tires and for solo projects that you can comfortably run on your laptop.
(Remote) Kubernetes
This is a great pick for teams building apps that run on Kubernetes because:
It allows you develop in remote, production-like environments that scale with your stack.
You don't need any dependencies on your laptop, even the builds happen remotely.
It allows you to share build and test caches with your entire team and across environments. This can dramatically speed up pipelines and development.
It allows you to easily create preview environments that you can share with others, e.g. for pull requests.
Terraform
It allows you to:
Reference outputs from your Terraform stack in your other services. You can e.g. pass a database hostname to a given service without "hard coding" any values.
Provision infrastructure ahead of deploying your project in a single command.
Pick this plugin if you're already using Terraform and want to codify the relationship between your runtime services and Terraform stack.
Pulumi
Local scripts (exec)
exec)It's great for executing auth scripts, running services locally, and as a general purpose escape hatch.
It's built in which means you don't need to specify it in the project level configuration and you can simply add exec modules right away.
Step 2 — Add your modules
Once you've configured your plugin(s), it's time to add modules.
Modules are the components that make up your stack and can contain services, tests, and tasks.
How they're configured depends on the module types and plugins you're using.
We recommend putting each module in its own garden.yml file and locate it next to any source files. For demonstration purposes, here's what a (slightly simplified) Garden project could look like in a single file:
Depending on the size of your project, you may want to add a handful of modules to get started and then gradually add more as needed.
Step 3 — Add more plugins and environments
Garden works great during development, and for running tests and creating preview environments in CI.
We recommend adopting Garden in one part of your software delivery cycle to begin and then gradually introducing more.
A common path looks something like this:
Start by using Garden in CI to create preview environments.
Roll Garden out to developers and add production-like dev environments.
Use Garden for running end-to-end tests, as you code, and in CI pipelines.
Use Garden for production deployments or integrate it with your existing tools.
At this point, a simplified configuration could look something like the following:
At this point you'll have codified all your workflows such that they are portable across environments and you can go from zero to a running system in a single command.
Now that you have a feel for how our users typically adopt Garden, we recommend heading to the documentation for your plugin of choice, and to start Gardenifying your project.
Last updated
Was this helpful?