Formalize need for BYOC backend for new project/service contributions.
When we have a contribution of a new project or a new service to OSDU, different dev teams need to be able to quickly try out the code and understand the behavior beyond the overview/walkthrough done by the contributing team.
However in order for our dev teams to be able to run/debug the service and associated integration test themselves, requires the dev team to have access to the deployment environment of the contributor and their underlying CSP secrets, keys etc., which causes latency in understanding and adoption of code within OSDU platform.
BYOC back-end is intended for this purpose, but we haven't required this as part of any contribution. It may be worth considering this as a first step in project contribution after the code is authorized for inclusion in community Gitlab, so we can make the above easier.
Requirements
- BYOC back-end implementation for any new service or project contribution to OSDU platform
- Ability for all CSPs and other platform developers to be able to run the service, test-suite independent of the original contributor's infrastructure
- Associated CI/CD updates to ensure it can be run independently w/BYOC and (ideally) on a developer workstation.
Operator Input
- Pending, but this is more of a PMC governance and process streamlining issue.
Definition of Done
- After Code is scanned and validated for contribution, contributing team works on a BYOC backend
- new service and/or project is able to pass the integration tests with a BYOC backend
- basic documentation is included on how to build/run against BYOC to learn about this service or project