Hi Hunter,
The simplest and most successful approach I've had is using a monorepo with trunk-based development.
Looking at your diagram, I would be cautious about creating long-lived branches for each gateway. I generally view gateways as deployment boundaries rather than development boundaries. The code should be developed once, integrated/merged once, and then deployed to many gateways. Your current approach requires cherry picking or multiple redundant merges.
I prefer:
- One shared codebase
- One source of truth (trunk)
- Short lived feature branches or commit straight to trunk
- Configuration driven application (tags, connections, custom JSON config, etc.)
- Independent deployments per gateway
This keeps feature development, bug fixes, and refactoring centralized while still allowing each gateway to have specific site behavior. It also avoids branch drift and the overhead of maintaining multiple long lived branches.
The main caveat is that a monorepo and trunk-based development require a strong CI/CD pipeline. Unit tests, functional tests, and automated validation should run on every commit to catch cross-cutting regressions before deployment.
For Ignition specifically, I would strongly recommend minimizing the number of projects and driving behavior through configuration whenever possible. I've written about that previously here:
I would push for a single project and drive your application entirely on configuration. Project inheritance for me has always been a headache (multiple designers, delayed updates, etc) and is the last tool I reach for.
For gateway configuration I use deployment modes per gateway rather than per environment. This allows me to make configuration changes across all gateways atomically in a single commit.
So far this approach has scaled well for us across multiple sites and gateways.
I hope this is clear and I'm more than happy to go into detail!