OSDU Data Platform Release Management
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.
Challenges with Mercury baseline setup
- 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.
- QA and pre-ship production test environments require test data sets (currently Volve and TNO) to be loaded so the system is tested with real-world data rather than fabricated ones in the unit tests within the CICD space in Gitlab projects.
These are the proposed environments for handling development, Automated QA and manual validation of the final product in preshipping.
Cognizant of costs and maintenance overhead, we categorize the environments to a smaller set of durable environments and an on-demand transient environment that can be instantiated for the duration of a given test or engagement.
Dev Primary Environment
- This exists today and linked to the community Gitlab CICD. The master branch regular builds rely on this environment for validating new MRs submitted to Gitlab. The environment currently runs project level unit and integration tests in an automated fashion. No platform level validation/integration tests are performed.
Dev Secondary Environment
- This is a proposed environment also linked to the community Gitlab CICD. This allows us to avoid a code freeze when the community reaches a milestone and to allow for parallel trusted builds to run for both the tagging/milestone builds in Dev2 and the mater branch MR builds in Dev primary. No platform level validation/integration tests are performed.
QA Automation Environment
- It is important for the community that the automated QA tests are done with a) real-world data sets (TNO, Volve, etc.) and b) with the representative deliverable they will receive from the provider/CSP own CICD. Note that the deployed environment does not pick up binaries from the milestone tagged version in community Gitlab, so the need to integrate the outputs from the provider/CSP CICD into the automated QA environment. Milestone releases should be pushed in here and all the integration (functional) tests will be run in an automated fashion here.
Preship Production Environment
- This is an environment that provides an opportunity for operators and potential OSDU consumers to volunteer and test as a representative end-user/customer. The feedback will improve both the community code quality and also the operational/security/deployment aspects brought to fruition by the provider/CSP.
QA Development Secondary Environment This a recommended environment to provide a stable environment for the QA team to build functional tests for new capabilities in the platform. This will start initially manual during test development before they can automate this to create postman/newman scripts. The goal is to explore, document and automate the test cases and append the suite to be ready for push into durable QA automation environment. At the moment the QA engineers will need to compete with automation tests and milestone updates in QA automation environment for their own development. Because this requires test data and the assurance before pre-ship it should also be fed with build artifacts from the CSP/provider's CICD rather than just the community Gitlab - so tests run in simulated prod environment.
Preship Secondary Environment for Operational Procedure Testing Because Production environment is mainly for operator and representative users to exercise the system before shipping out, the tests should assure the environment will not be impacted negatively. This means any tests around load/performance tests or operational tests such as disaster recovery, backup/restore, service rollback/roll-forward strategies need to be done in an isolated space. This environment is a transient setup that can allow for such potentially destructive tests - as a mock production environment, this should be populated from the CSP/provider's CICD rather than just the community Gitlab and the test data sets (Volve, TNO) should be pre-populated here.
Preship Secondary Environment for Security Testing This is similar to the previous transient preship secondary environment - any tests around security such as pen tests, port-scans, DOS attacks etc. will be done in this temporary but isolated space. As a mock production environment, this should be populated from the CSP/provider's CICD rather than just the community Gitlab and the test data sets (Volve, TNO) should be pre-populated here.
The following picture is a high-level recommendation for both durable and transient environments to be created
Current Status (In works):
CSP leads would be updating this table below shortly:
|Durable||Dev Primary||Exists (provide endpoint/details)||Exists (provide endpoint/details)||Exists (provide endpoint/details)||Exists (osdu-glab.msft-osdu-test.org)|
|Dev Secondary||Will create (provide details)||Will reuse from QA (provide details)||TBD?||Will reuse from QA (osdu-demo.msft-osdu-test.org)|
|QA Environment||Exists (4iqp6vd659.execute-api.us-west-2.amazonaws.com)||Exists(drgfbg5txq-uc.a.run.app)||Exists(osdu-cpd-osdu.odi-osdu-og-fa7661852f2ab29a6be32f560b2f5573-0000.us-south.containers.appdomain.cloud)||Exists(osdu-demo.msft-osdu-test.org)|
|Preship (Prod)||Exists (20ve0a34we.execute-api.us-west-1.amazonaws.com)||Exists(drgfbg5txq-uc.a.run.app)||Exists(osdu-cpd-osdu.odi-osdu-og-fa7661852f2ab29a6be32f560b2f5573-0000.us-south.containers.appdomain.cloud)||Exists (osdu-ship.msft-osdu-test.org)|
|Transient (On-demand)||QA Dev||TBD?||TBD?||TBD?||TBD?|
|Preship secondary – operations tests||TBD?||TBD?||TBD?||TBD?|
|Preship secondary – load tests||TBD?||TBD?||TBD?||TBD?|
|Preship secondary – security tests||TBD?||TBD?||TBD?||TBD?|
Here is an example of how to get the end-points for the various OSDU services using the base URL provided above by the different cloud providers. Contact cloud provider leads for details on Authorize_EndPoint, Token_EndPoint for OAuth2 authentication and to obtain the tenant_id, client_id and client_secret values for authentication.
Listed below are Azure examples for the QA environment:
- Partition Service = https://osdu-qa.msft-osdu-test.org/api/partition/v1/swagger-ui.html
- Entitlement Service = https://osdu-qa.msft-osdu-test.org/entitlements/v1/swagger-ui.html
- Legal Service = https://osdu-qa.msft-osdu-test.org/api/legal/v1/swagger-ui.html
- Storage Service = https://osdu-qa.msft-osdu-test.org/api/storage/v2/swagger-ui.html
- Indexer Service = https://osdu-qa.msft-osdu-test.org/api/indexer/v2/swagger-ui.html
- Search Service = https://osdu-qa.msft-osdu-test.org/api/search/v2/swagger-ui.html
- File Service = https://osdu-qa.msft-osdu-test.org/api/file/v2/swagger-ui.html
- Delivery Service = https://osdu-qa.msft-osdu-test.org/api/delivery/v2/swagger-ui.html
- Register Service = https://osdu-qa.msft-osdu-test.org/api/register/v1/swagger-ui.html
- Notification Service = https://osdu-qa.msft-osdu-test.org/api/notification/v1/swagger-ui.html
- Unit Service = https://osdu-qa.msft-osdu-test.org/api/unit/swagger-ui.html
- CRS Catalog Service = https://osdu-qa.msft-osdu-test.org/api/crs/catalog/swagger-ui.html