Garden supports in-cluster building, using buildkit or kaniko.
This way, you don't need to have Docker or k8s running on your dev machine as you're working.
It also automates the process of redeploying services and re-running tests as you're coding (since it leverages the build/deploy/test dependencies in your stack).
We also provide hot reloading of running services, which brings a similarly fast feedback loop as with local dev.
The idea is to have a dev environment that has the same capabilities as the CI environment, and to be able to run any/all of your tests without having to go through your CI system (which generally involves a lot more waiting).
We already have some home-grown kubernetes dev environment in which every developer/QA can spin up all of our services in a dedicated namespace, but it's a bit tedious and spaghetti-code as it grew organically over time (from a 15 devs team to a +70 one). Garden looks like a nice alternative solution, do you think Garden Core is enough to get started? (we like to get our hands dirty)
Sounds like Garden Core could be a great fit here.
The motivation behind Garden was that, like you, we had built our own home-grown kubernetes dev environments, but felt like there should be a polished, general-purpose framework + tool for this sort of thing.
Hi, another Gardener here. Garden Core should indeed be enough to get started. I'm trying to keep this as factual and non-pitchy as possible for the sake of providing context—the enterprise product gets you:
• RBAC and secrets management (also makes it possible to control which users have access to which types of environments)
• Direct integration with GitHub or GitLab, so you could trigger something to happen in Garden based on a VCS event
Garden supports in-cluster building, using buildkit or kaniko.
This way, you don't need to have Docker or k8s running on your dev machine as you're working.
It also automates the process of redeploying services and re-running tests as you're coding (since it leverages the build/deploy/test dependencies in your stack).
We also provide hot reloading of running services, which brings a similarly fast feedback loop as with local dev.
The idea is to have a dev environment that has the same capabilities as the CI environment, and to be able to run any/all of your tests without having to go through your CI system (which generally involves a lot more waiting).