Hi All, I'm looking into introducing garden (I really love the idea) and I'm trying to clear in my head how it fits with the way our repos are structured and our code is deployed so I can try get a POC running. We have multiple backend services spread across a few mono-repos (each repo represents a feature of the product, and has a directory per service that makes up that feature), another repo represents our frontend/UI, and a final repo contains the Jenkins jobs for testing post-merge. Each service has a Dockerfile and builds and pushes a helm chart. Our CD repository contains environment configurations. At a surface level this repo is made up of a directory per env. This env directory contains one large values.yaml, and subdirectories per service to be deployed with a yaml file describing the helm chart to deploy. Questions 1. Given the multi-repo nature of the code, are remote sources the right approach or is there something different I have missed? 2. Given all the code repos are of equal importance, where should the root garden project file have its own repo? It seems either: the CD repo, or a similar decoupled repo should store it, OR each dev team has their own garden project in their repo that lists their dependencies as the other repos?

Hi @proud-river-11384 and welcome to the community! This use case is perfect for Garden. > Given the multi-repo nature of the code, are remote sources the right approach or is there something different I have missed? Since you're pulling in environment configs from your "CD" repo, remote sources will be your friend here. > t seems either: the CD repo, or a similar decoupled repo should store it, OR each dev team has their own garden project in their repo that lists their dependencies as the other repos? There's a few ways to skin this cat. I'd encourage you to start small and experiment to see what fits your teams. For example, you could create

configmap

actions in the CD repo that get mounted by your Helm charts as single remote actions. Personally, I am a strong advocate for teams controlling their own destiny, inspired by Kasper Nissen, CNCF Ambassador at Lunar. So teams owning their own Garden projects sounds like the right move to me. But this doesn't need to be an either/or scenario. Teams could consume

configmap

actions from CD in their own

helm

actions. If you wanted more control and/or less complexity, you could vend Config Templates, which are essentially vended abstractions over one or more other actions. Gonna post some links below for you to get started on your Garden journey 👇 https://docs.garden.io/reference/action-types/deploy/configmap https://docs.garden.io/using-garden/config-templates https://buoyant.io/blog/developer-platform-with-linkerd-and-garden https://docs.garden.io/advanced/using-remote-sources Let me know if you have any other questions! Also happy to jump on a call with you and your team to chat 🧑‍🌾

This makes sense - essentially each team can have their own garden project in their own repo. I've realised the other services they would need to deploy have helm charts in a registry so they need to pull them instead of pulling in other repo sources. Trying to get a single service up and running using helm action as a start

Awesome, let me know how it goes