Subject: GitOps with Fleet - Dev/Prod environments on same clusters - Seeking advice Hi Fleet community! 👋 We're learning Rancher Fleet and need advice on our GitOps setup. Our Setup: • Multi-cluster application with

master/

(central components) and

fleet/

(edge components) folders • Need dev/prod environments running on the same physical clusters (resource constraints) • Want GitOps workflow: work on

develop

branch → merge to

main

for production The Problem: When merging

develop

→

main

, we get conflicts because environment-specific configs (NodePorts, namespaces, experiment names) differ between environments: yaml

# develop branch: nodePort: 30500 
# main branch:    nodePort: 31500
# After merge:    💥 CONFLICT!

Solution 1: Using Fleet's base + overlays pattern:

master/
├── base/                    # Common resources (identical in both branches)
│   ├── deployments/
│   └── internal-services/
├── overlays/
│   ├── development/         # Dev-specific configs (ports 30xxx)
│   └── production/          # Prod-specific configs (ports 31xxx)
└── fleet.yaml

Solution 1bis: Fleet's base = production and overlays apply changes only for development: Easier to manage and to implement

main branch (Production):
├── base/                    # Production configs (default/stable)
│   ├── deployments/
│   └── services/
└── fleet.yaml               # No overlays needed

develop branch (Development):
├── base/                    # Same production configs  
├── overlays/development/    # Dev-specific overrides only
│   └── dev-configs.yaml    # Different ports, namespaces, etc.
└── fleet.yaml               # Uses development overlays

4 GitRepo resources total (master-dev, master-prod, fleet-dev, fleet-prod) pointing to different branches and using different overlays. Handling Fleet.yaml Merge Conflicts: Using

.gitattributes

with

merge=ours

to automatically keep production fleet.yaml during merges:

# .gitattributes
*/fleet.yaml merge=ours

This ensures when merging

develop

→

main

, Git automatically keeps the main branch fleet.yaml (production config) and discards the develop branch version. Questions: 1. Is one of this solution the right approach for our use case? base=prod + overlay=dev approach a Fleet best practice? 2. Any issues with our

.gitattributes merge=ours

strategy for fleet.yaml files? 3. Any better patterns for same-cluster dev/prod separation? 4. Best practices for managing environment-specific configs in Fleet? 5. Alternative solutions we should consider? We're fairly new to Fleet, so any guidance from experienced users would be greatly appreciated! 🙏 Thanks in advance!

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