If you already have an MDOQ subscription you can view the interactive guide here
We also might refer to this as your Connector. This is required in order to deploy code to production and to take snapshots. Generally, this will be set up as part of your onboarding process. Production Instances are highlighted on the left via a blue tab.
These are standard MDOQ instances. These are used for all development and any other work including code changes. Some examples are:
- Applying patches
- Applying upgrades
- Installing extensions
- Fixing bugs
When work is complete, typically you would merge it to UAT, unless it was a critical bug fix in which case you could deploy it straight to master/production.
MDOQ does not enforce any particular working methodology for developer workflow, you are free to adopt your own.
Release Candidate / Non-Prod Instance
These instances are NOT for development, however there are good reasons why many clients will have 2 instances of this type.
Non-Production Instance (NONPROD)
This should always reflect what is on your production infrastructure, either matching your master source control branch, or the latest tag (whichever practice you adopt). This gives a constant instance which can be used in these scenarios.
- Automated Regression Tests - You can use systems like Selenium or GhostInspector to test features
- 1st Line Support Testing - if you have reports of issues on production that need further investigation, then this instance will allow you to replicate and initiate your investigation.
User Acceptance Testing (UAT)
This instance is where multiple work items or work packages can all be merged and tested together, it is therefore always considered to be ahead of 'master' and therefore should not be confused with NONPROD.
Scenarios for UAT:
- Client acceptance of tasks
- Manual testing
- Regression testing