There’s plenty of room for improvement in the typical development workflow for Kubernetes.
One area in particular is the development feedback loop. The shorter the feedback loop, the more you stay in the creative mindset — which, in turn, is what makes coding so much fun.
But in most workflows, every time you change a service that’s running on Kubernetes — be it a major upgrade or just fixing a typo — there are lots of steps between writing your code and your changes going live.
It usually goes like this:
- Change your code
- Build a new container image: <span class="p-color-bg">docker build . -t myimage</span>
- Click the caramel mocha cappuccino, half soy & half almond milk, with whipped cream and pumpkin spice powder on top button on your coffee machine.
- Push your container image: <span class="p-color-bg">docker push blabla</span>
- Drink the aforementioned caffeinated wonder
- Apply the new image to your cluster: <span class="p-color-bg">kubectl apply -f mynewcode.yml</span>
- Pray to your deity of choice that you’ll still remember what the code change was about.
I exaggerate, but it holds true:
Manual busywork in between code changes makes for a long feedback loop. And the longer the feedback loop, the more likely that you’ll lose the mental context of what you were working on.
Ideally, you shouldn’t do any busywork by hand — or even notice it’s there.
Here’s A Solution
None of this is an issue if you have tooling watching your code and doing the whole process in the background.
This way your services are always up to date on your development cluster, and you can iterate quickly and without losing focus.
However, if your tooling rebuilds your whole application on every code change, it’ll be very slow.
If, on the other hand, it redeploys only the service you’ve changed, it might break services that depend on it — changing a schema, or a port on a config file, for example, might require dependent services to redeploy as well.
So ideally your tooling will have a dependency graph. It can then map the dependencies between your services so that, on code change:
- It rebuilds the service you’ve changed;
- It rebuilds and/or redeploys its build and runtime dependencies;
- And nothing else!
By doing only what’s necessary and nothing else, your workflow stays fast and snappy — and you can skip some of those caramel mocha cappuccinos.
And In Practice
Now let’s implement this with Garden.
If you’re not familiar with Garden, it’s a development orchestrator. It aims to remove as much friction as possible from developers’ workflows, especially when working with Kubernetes.
Garden runs as a CLI tool and does, among other things, what we described: it watches your application’s source code, and rebuilds and redeploys in the background as you work on your code.
Configuration
This is the basic configuration to run a project with a single service in Garden. You place it as <span class="p-color-bg">garden.yml</span> in a directory on your filesystem, and your code goes either there or in a subfolder. Click here to check out the repo.
The top part describes the project, and the bottom part describes a service — Garden calls the different parts modules.
We’ll replicate that bottom part when we add another service.
Let’s Run It
Running Garden with this setup gives you that magic workflow we discussed, where changing code triggers a rebuilds and redeploys unobtrusively in the background— manual input not required. Check it out here.
Now With Dependencies
Let’s add the whipped cream— I mean, the second service, so we can see how to set up dependencies.
Just as an example let’s make a service <span class="p-color-bg">two</span> that’s dependent on service <span class="p-color-bg">one</span>.
First we create a subfolder named <span class="p-color-bg">two/</span> with some code in it. Then we create a <span class="p-color-bg">garden.yml</span> in it with the following content:
Because we’re specifying a dependency, this will result in a dependency graph:
And the resulting behavior, as you’d expect, is that changes to service <span class="p-color-bg">one</span> will trigger a redeployment of service <span class="p-color-bg">two</span> as well, see here.
Because service “two” depends on service “one,” changing service “one” triggers a redeployment of service “two.”
In Conclusion
With the workflow above we automate a lot of the manual work that’s usually necessary when developing for Kubernetes.
While some setup is required, and the caffeinated beverages industry might object, as developers this makes for a workflow where you can focus on what really matters — and have fun doing it.
To set up Garden for your own projects, check out the Quick Start guide!
