Git Repository Structure and Asymmetric Deployment Modes Strategy

Ignition
,
1

Hi everyone,

We are planning our migration/implementation workflow under Ignition 8.3, leveraging a Scale-Out Architecture. Our infrastructure consists of:

  • Multiple Frontend Gateways: Handling Perspective and UI.

  • Multiple Backend Gateways: Functionally identical in terms of global logic and scripts, but with distributed/asymmetric devices mapped across them.

To add context, our environments are unbalanced: we have 5 Backend Gateways in PROD (each with unique device connections) and 2 Backend Gateways in TEST (with different, potentially simulated device connections).

As we adopt the new file-system structures and Deployment Modes in 8.3, we are re-evaluating our version control and deployment pipeline. We would highly appreciate the community's feedback on our current questions and our proposed strategy.

1. Repository Structure: Micro-repos vs. Monorepo?

Right now, we are separating everything into independent Git repositories (separate repos for Tag Definitions, UDTs, Global Project, Scripting, and Frontend Perspective).

  • Given the new 8.3 architecture, is this highly granular approach still recommended, or is the community moving towards a unified Monorepo per Gateway type (e.g., one Monorepo for Frontends, one Monorepo for Backends) to avoid dependency issues?

2. Deployment Modes in Asymmetric Scale-Out clusters

Since our backends within the same environment are not identical clones (Backend A has different devices than Backend B), a simple "TEST" and "PROD" deployment mode structure doesn't fully cover our needs.

  • Can Deployment Modes natively handle hierarchical overrides? (e.g., a Core mode inherited by an Environment mode, which is then inherited by a specific Gateway mode?) Or does this overcomplicate the 8.3 native structure?

3. Strategy Validation: Hybrid Instance-Profiles + OS Env Variables

To solve the asymmetry between our 2 TEST backends and 5 PROD backends, we are designing the following hybrid architecture within a Monorepo, and we want to validate if this is considered a solid best practice:

  • Instance-Level Overrides in Git: Instead of environment-wide modes, we create 7 distinct Deployment Modes representing each physical/logical server instance (prod-backend-1 to prod-backend-5, and test-backend-1 to test-backend-2). These folders will exclusively contain the configuration overrides for that specific gateway's local device connections.

Our questions for the experts:

  1. Is combining granular, instance-specific Deployment Modes in Git with OS Environment Variables for the network/database layer considered a robust and scalable practice in Ignition 8.3?

  2. Are there any hidden pitfalls or performance issues when scaling the number of individual deployment mode folders inside a single repository?

  3. Would you manage this differently (e.g., keeping devices entirely out of Git and managing them via EAM/manually)?

We would love to hear your thoughts and experiences managing similar large-scale setups with the new 8.3 features.

Thanks in advance!