This page serves as a documentation of the different environments that are used to develop, test, qualify and release the OSDU data platform on the various supported cloud backends.
## Environments Proposal:
These are the proposed environments for handling development, Automated QA and manual validation of the final product in preshipping.
* With only one dev environment in community Gitlab, trusted builds cant be run in parallel without impacting the CD/integration tests in the target environment. This forces a code freeze at milestones to allow tagging and completion of
* _Note _- OSDU data platform is composed of multiple projects and each project's CICD only tests their own integration tests to identify a green build. However the platform wide sanity would require a consistent green build across projects. Example a change to indexer service that happened after search service may deem indexer as passed but you need to retest the search to catch the disconnect.
* Manual testing of end-to-end and exploratory tests require some assurance for the testers that the system has passed the automation tests for integration and functionality. Without a clear separation of the manual test pre-ship/emulated production environment and the automated test execution QA environment, this assurance doesn't exist in Mercury
* QA automation test developers also require a stable baseline with green build to develop/validate their test suites. Today this is done either in pre-ship or in QA/execution environment. Doing in pre-ship implies test suites are developed where production users are doing e2e tests already (see assurance comment above). Doing in QA environment implies having a durable QA environment (not available in all CSP) and qualified milestone deliveries into the QA.
## Environment Definition
Recommendation is for some durable environments to be created
