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.
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
