I am finally starting to dabble with v8.3, and I'm not sure which way to go with the deployment overrides.
Should I setup my core DB connections with development settings, then add overrides for a production collection, or should I have core, dev, and production configs? This seems like a lot more duplication, but I will do it this way if it has some benefit.
I prefer a configuration where core contains the entirety of production resources, then add other deployment (dev & stg) overrides to that base.
It has been convenient developing workflows where the entire production config is contained in a single folder.
I agree with @Chris_Bingham . The number of overrides you need for a dev and staging environment tend to be small so keeping core as production makes the most sense IMO.
That makes sense, but it seems a little risky using core for production settings. If a test gateway gets spun up without a deployment mode setting, production connections would be the default.
Deployment modes aren't a substitute for proper network isolation, IMNSHO. Modes can and should supply the alternate targets needed match the isolated environment.
Most of my confusion came from every example and demonstration I have found on deployment modes end up showing production/dev separate from core.
Fair point on the networking isolation.
That certainly is a logical design choice. With CI/CD automated workflows, the sky is the limit...for better or for worse.
In my preferred, changes to core (=prod) also end up in other deployment modes by default - whereby overrides are required in those environments to restrict access (or redirect connections). This might stem from our current workflow (subject to change as CI/CD is embraced) - where minor changes are performed directly against the prod gateway. I.e. The prod gateway is the source of truth (not the repo). That design choice might have some undesirable outcomes in your architecture. So, you might decide to create read-only (or undefined) connections in core and override them with read/write connections in a dedicated prod deployment mode.
In a larger SCADA architecture we're building, we're planning to utilize external for shared resources between all nodes.
Perhaps relevant (and well-timed):