Git Repository Structure and Asymmetric Deployment Modes Strategy

[hflores]

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!

[Noah_Burnette]

Hello,

There is a lot here. I would first recommend to look at the ignition documentation:

Version and Source Control Guide | Ignition User Manual

Best Practices for Using Git in a Team Environment | Ignition User Manual

Gateway Deployment Modes | Ignition User Manual

For monorepos I like the trunk based development approach. I have had much success with it.

Based on the phrasing of your questions, please take a look at the guidelines on AI content.

More than happy to take a look at your current implementation and layout if you post it here.

[louagejasper]

@hflores

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?

Monorepo is the best if your organisation structure/vendor structure allows for that. Way easier to manage.

@hflores

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?

Deployment modes are for test, staging production, not meant for different gateways handling completely different devices. You will need one config structure per gateway. (automations/shared stuff is still possible in a monorepo.

@hflores

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.

Imo you are abusing deployment modes here. What you should be building are pipelines that deploy to different gateways based on the environment you are deploying to.

@hflores

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?

No, you will need to have different configs per gateway. Deployment modes are only good for handling differences on gateways that fulfil the same role, but just in a different environment.

@hflores

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

No, not really, but you will get yourself in a unmaintainable solution. You can achieve what you want without abusing the deployment modes.

@hflores

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

Everything in Git, use deployment modes for what it is good at, no EAM.

[Noah_Burnette]

@louagejasper

Imo you are abusing deployment modes here

I think this is strong wording. That is absolutely how we deploy our configuration changes to our gateways. I spoke with IA at proveit! about this approach and they said that it was perfectly valid. It works ridiculously well. I can spin up a single gateway and make all my configuration changes there in a single commit and all within the gateway UI.

[louagejasper]

@Noah_Burnette

I think this is strong wording. That is absolutely how we deploy our configuration changes to our gateways. I spoke with IA at proveit! about this approach and they said that it was perfectly valid. It works ridiculously well. I can spin up a single gateway and make all my configuration changes there in a single commit and all within the gateway UI.

Might have been strong wording. I'm open, but I guess I never looked from that perspective. So you have you device config only in the deployment modes? So in overrides you just have entirely different devices, not just overrides on the devices in core?

I still do wonder why would you not just handle it in the deployment pipelines? You would still be able to edit everything in one gateway, since you can mount all folders to your one development gateway.