Handling Production class in source control
Looking for advice on best practise (or at least reasonable approaches) for handling the Production class when utilising source control. (And perhaps wider advice around deployment.)
Scenario: a production server, a UAT test server, a connected development server plus multiple local development servers. In a particular (HL7 focused) namespace the production has an in-coming feed, more than a dozen downstream TCP connections, half a dozen downstream SQL connections, an email connection... The settings (eg IP/port number for the TCP connections, DSN for the SQL connections, etc) will all be different between live, test and development productions.
Let's say developers are asked to add a new downstream TCP connection, with some new routing/transformations - so there are new business processes and operations. We'd like to capture those new elements of the production in source control - but we don't want the production connectivity settings in the development environment (developer: "sorry, I didn't mean to hook my half-built code to the live XXX server..."!). Both the connectivity settings for each component and the details of the components themselves are captured within the Production class - so thoughts on how this can be elegantly handled?
If there are other tools for handling (parts of) this scenario that we've not come across, eg by importing a set of connectivity settings at the point a production is deployed, we'd be very interested.
FWIW, our source control is git/GitLab via VS Code on the development servers. Currently we deploy by exporting changed/new classes from the development servers by XML and importing those into the UAT and subsequently live environments.
Currently using Ensemble, but an upgrade to Iris HealthConnect in the pipeline.
Use System Default Settings?
That looks ideal, thanks! Almost like it was designed to do the job we are looking for...! 🤣 Will investigate properly for our specific situation.
Eduard is correct ... System Default Settings are the proper way to handle this. we will also export the SDSs to store in a non-progressed branch in Source control to use as snapshots of the settings per environment over time (there is an export API you can use for this .. it doesn't tie into source control hooks).
If you're using git/Gitlab you can have System Default Settings file (export, import) specific for each deployment.
And get the path as:
config/SDS/$CI_COMMIT_BRANCH.xmlThis way the code is the same everywhere, and you only load one SDS file, depending on the current environment.
It's also possible to override the adapters and get the data from your own data within the namespace.