Single and Multiple Configuration Servers

There are advantages and disadvantages when hosting builds either on a single server or on multiple configuration servers. See the following options:

Option 1 - Single Configuration Server (Single Build)

From Lasernet 9 onwards, you can have a build hosted on a configuration server/service and use that one single build. All changes can be updated in that one build and deployed as needed to different instances. The advantage is that export/import between builds is not needed.

The downside is when multiple people make amendments at the same time and then commit. They need to ensure (as a process) that only approved amendments are committed (testing can be done with patching) and other changes still being tested aren't included in the commit, for when this commit is deployed to Live. For example, a form is committed on Test but is not ready to be deployed to live, then you cannot deploy this commit to Live even if it includes something that has been approved for Live as it will appear on Live. This may work if you have a clear work process on amendments.

Option 2 - Multiple Configuration Servers

For this, you would have a config server for each server. Users can then export and import between the builds. Deployment is fine (with little impact on other instances, unlike Option 1, as each server is entirely separate.

Option 3 - Single Configuration Servers (Multiple Builds)

A single config service but with multiple builds for each instance. Forms and amendments (once approved) will need to be committed and then exported and imported into another build, ready to be deployed to that instance. There isn't the disadvantage of Option 1, where deployment deploys on all instances as long as the build only contains that exact instance.