This message was deleted.

1. this will always be controversial. I don't prefer overlays, but I'd lean toward number 1 to encourage clarity, even if the production folder doesn't have overrides. 2. I don't have any input, I don't like using trunks for non-ephemeral environments. 3. use folders instead of long-running branches (trunks) where possible. 4. consider separating configs from values, perhaps by separating repos. 5. comments in the above responses

Thanks @witty-honey-18052 for the detailed insights! 🙏 We actually tried our Solution 1bis approach first (base = production + overlays for dev only), but ran into stability issues. The overlay mechanism got confused when trying to patch development resources that were already "baked into" the base - it was particularly problematic with complex resources like our MLflow Helm deployments and multi-port services. That's why we switched to explicit overlays for both environments (Solution 1) - it made the overlay behavior much more predictable, even if it means some duplication. Your folder-based approach opened my eyes to real Kubernetes file structuration and more sophisticated deployment patterns! The separation between

applications/

(templates) and

environments/

(values) is exactly the kind of enterprise-grade architecture I need to understand better. This brings up an interesting question though : in terms of k8s deployment, environments are not managed by git branches !? For our current lab setup, we'll stick with our working solution, but I'm definitely going to explore the folder-based + templating approach for our next project. The

.gitattributes merge=ours

is more of a "quick fix" than a proper architectural solution. Really appreciate you taking the time to explain these patterns - exactly the kind of guidance we needed as Fleet newcomers! 🚀