CI hurts. As our friends at Obligate told us, “Most devs experience a pipeline that will run for God knows how long and the tests simulated have nothing to do with production.” This is the problem we set out to solve with the new Garden 0.13 release, which we're calling Bonsai.
We started Garden to give developers production-like environments where they could be sure that what worked on their local machine would also work in production. But it turns out that a tool that can spin up dependency-aware ephemeral environments can also create portable CI pipelines that run in a few minutes instead of hours.
Once you start making cloud-native systems easier to work with, you find ever more opportunities to provide structure and automation.
In this post, we’ll talk about Garden’s Bonsai release and how it provides a more expressive and intuitive way to write CI automation for Kubernetes. For more information about moving from 0.12 to 0.13, read our migration post.
What we’ve learned
Abstractions are all about noticing patterns.
That's where Garden's design came from — we noticed that almost all dev automation and CI pipelines boil down to a sequence of a few basic types of operations:
- Builds
- Deploys
- Tests
- Runs (for all those pre/post steps, e.g. to set up auth, or load DB schemas and data)
Garden uses these definitions to create the Stack Graph, which works as a blueprint for the entire system. You can describe your system once and deploy it anywhere (prod, dev, QA, etc.). That means devs can work in environments that are actually production-like and stop the cycles of commit, push, wait. This was, of course, the idea.
And it’s still the idea — improving developer experience with production-like environments is at the core of what Garden does — but along the way, we realized that the Stack Graph has even bigger implications for DevOps and Platform teams writing pipelines.
Our 2021 developer productivity survey found that developers spend 5–6 hours a week waiting for slow pipelines. Customers echoed this feedback, saying that the biggest pain point for developers was waiting for CI.
This was a pain point Garden was already solving — one Fortune 500 team used Garden to automate their CI pipeline, reducing its run time from an hour to two and a half minutes — but we wanted our abstractions to better match this pattern. That is to say, we wanted to match the vocabulary of Garden with the way that people instinctively describe the domain.
If you've been using Garden before, you will have configured your project using modules. We still support those in order to ease the transition, but over time we are phasing these out in favor of the new more granular Actions.
Garden Actions, as part of our Bonsai release, provides an intuitive way to describe your CI pipeline with four actions: build, deploy, test, and run. This creates context, so you’ll be able to write less boilerplate and spend less time debugging. It’s a new way to write CI automation with Kubernetes. We think you’re going to like it.
Garden Actions: A new, more expressive language for CI automation
The hard part of CI is creating the environment. That’s when you need to execute a specific sequence of actions in a specific order (e.g. building, deploying) to ensure the environment will accurately reflect production.
When you look at a traditional CI pipeline for a big project that uses many services, it has a graph-like structure that is used to execute the actions necessary to spin up those environments.
That means that large parts of the pipeline (say, 80% of it or more) are spent on building, deploying, and general non-testing activities. So why are we encoding this information in CI script steps?
A legible, portable pipeline
When you codify this sequence of actions with the Stack Graph, you create a portable pipeline so that your stack is rebuilt the same way every time, in CI or on your local machine. Deploying your pipeline becomes as easy as writing <span class="p-color-bg">$ garden test</span> or <span class="p-color-bg">$ garden deploy</span>.
This means your tests will always match production.
The Stack Graph is change-aware, which means instead of rebuilding or retesting the whole stack every time it is deployed, which can take hours, Garden only rebuilds or retests changed code, cutting testing time down to minutes.
The Stack Graph isn’t just a transcription of steps like GitHub Actions and similar tools. Garden Actions gives each of these build, test, and run steps their own definition and context. By giving each action type its own semantics, we make actions easier to write and assemble. Users can write and debug less while the CI pipeline understands more.
In the end: It’s a lot easier for DevOps and Platform engineers to lay out CI pipelines and dev automation with Garden. And, it's a lot easier for developers to interact with them.
Bonsai, beyond Actions: First class developer experience
Bonsai isn’t just about actions. It includes a suite of improvements in response to customer requests including a powerful interactive development console and a new cloud-based dashboard.
The shift is toward greater flexibility, extensibility, and (should we just say it?) power both for local development experience and for CI.
Interactive development console: A seamless inner loop experience
Developers are often forced to juggle various tools as they work on different parts of their application and conduct code review.
The new interactive dev console puts everything at your fingertips in a faster, more intuitive way. It’s one interactive prompt where you can do everything — build, deploy, test, start or stop code syncing, stream service logs — all with autocomplete in a persistent command-line.
This development console provides a seamless one-stop shop for everything you need while you're working on your stack so that you can stay focused in one place, with less waiting, less futzing, and less frustration.
Web-based dashboard: An intuitive interface for rapid iteration
For every developer who prefers a CLI, there’s another developer who prefers a rich graphical interface. Our web-based dashboard provides an intuitive interface for understanding what's going on in your stack as you're working on it.
You can see all your logs and statuses, stop and start syncs, and run any command that you can run in the CLI — in some cases, with more control and visibility than is possible in the CLI.
You’ll find that this tab is open all day, every day.
Announcing: Early access for Garden Desktop
But wait! There’s more.
We’re excited to announce early access to ✨Garden Desktop✨! Keep everything Garden-related in one place: No need to have multiple terminal windows open or search for the Garden Cloud tab in your sea of Chrome tabs. If it’s running in Garden, it’s one keystroke away. Full-screen your IDE, we dare you! Also toting:
Global hotkey: The ability to bring up a command palette at any time with a single hotkey (Cmd+Shift+Space by default but customizable), quickly run tests and actions, bring your development environment up, etc.
Autocomplete: Get suggestions for the Garden commands available to you and spend less time trying to remember which arguments that command takes.
Recently run commands: Keep running the same test over and over again? Cmd+Shift+Space -> Enter. The commands you run the most frequently are conveniently brought to the surface.
Head over to our docs to get up and running with our Quickstart Guide. If you run into any problems along the way, our friendly experts are on Discord to get you squared away.
Getting started with Garden
For enterprise users, the benefits of saving developers four-plus hours per week of waiting for slow pipelines and wrestling with tools, multiplied by hundreds of developers, equals massive savings. It means each developer on your team can have the equivalent of five extra weeks per year to ship new features. It means software ships faster, so companies capture revenue sooner. It means the ROI on Garden is measured in weeks, not months.
Schedule a chat with us to find out more.
