Release Core, Extensions, Domains, Domain Data Flows and Layered Services as described under Projects independently. It should be possible to release each of the domain DDMS or domain data flows or layered services as and when they are ready on top of the R3 core.
*Note: *The requirements in this page for the R3 scope were distilled from the various backlogs in Program Activities ( in particular Shared Backlog) and from OpenDES pending contributions moved to R3.
As the scope for the OSDU platform expands as mentioned above to domains and extensions it is important that we keep agility in the system and provide a reliable core that projects under extensions and domains can use to work in parallel. This list describes the principles that will be used in R3 timeframe to ensure agility, governance and transparency in the platform development.
Definition of Done:
- Definition of Done - R3 deliverables.
Release 3 Discussions
Architecture and Design
These discussions focus on Architecture and Design Decisions specific to Release 3
Release 3 Backlog
- Backlogs for Jul 1st
- High Level R3 Epics/User Journeys - very early draft! incomplete.
- High Level R3 Backlog
- Capturing Backlog - Use Issues to capture the backlog items & Use Labels to categorize the issues for the boards
Timeline and Dependencies
For effective parallel development and delivery of domain DMS, data flow and layered services independently we prioritize projects 1 (Core) and 2 (Data flow and Reference/Helper services) first to establish the platform as hub and spoke model.
The first priority now is to get the R3 codebase populated (see Initial Steps ) and to get the core changes described under here and to keep the Core stable and reliable for further development and delivery of Extension Projects and Domain Projects.
- Supercedes table below
- This is a distillation of what is in the backlog "done" page and better reflects the sequence of delivery (priorities) from a capability and continuous delivery perspective than the duration of development.
- Some of the longer duration lines are long because defining what is important often takes more time than defining how to do it. Right now my confidence in Milestone 1 is P80, Milestone 2 is P50, and nothing beyond that has had any analysis - Stephen
Draft timeline is detailed below:
Click to view timeline!
gantt title R3 Release Timeline dateFormat YYYY-MM-DD section Core Framework Core Project :crit, a1, 45d Data flow and Helper :crit, 2020-05-18, 45d section Domain Data Flows Generic Parsers/WKS :2020-06-15, 45d Wellbore parsers/enrich :2020-07-01, 60d Seismic parsers/enrich :2020-07-01, 60d Energistics Formats* :done, 2020-08-01, 60d section Deployment and Operations CICD on Gitlab :active, de2, 20d Deployment Readiness :2020-05-18 , 60d Operational Readiness :2020-07-01, 90d section Domain DDMS Wellbore DDMS :2020-07-01, 90d Seismic DDMS :2020-07-01, 90d Reservoir DDMS :done, 2020-08-01, 90d Well Planning DDMS :done, 2020-08-01, 90d section Layered Services Multi-regional OSDU* :done, 2020-08-01, 90d Federated OSDU/EDS* :done, 2020-08-01, 90d
Scope for Core Project(1):
Click to view core project scope!
- Maintain R2 OSDU Libs & core Services (search, Storage, ...) from CSP
- Data change Notifications from SLB
- Schema service from SLB
- DDMS enablement services - Registry and lookup from SLB
- Move File service as DDMS from CSP
- Data quality atttributes from TBD
- JSON Schema versioning
- Core common and CSPs libs versioning strategy
- Delete and privileged purge in Storage Service, ...) from TBD
- Search & Indexer
- Hierarchical/nested array of objects support in Indexer and Search service from CSP team
- Upgrade Elastic client version in Indexer
- Spatial index service* beyond R2 capabilities from TBD
- Security and Compliance
Deployment and Operations
- Global deployment, multi-region support from CSP
- Operations focused services - logging, metering, audit trails for cyber-security from CSP
- Disaster recovery and business continuity from TBD
- OSDU Contribution Guide(Project Structure, Apache License, Attribution, README..etc).
Scope for Data Flow, Reference and Helpers - Extension Project(2):
Click to view extension project scope!
- Reference and Helper Services
- Data Flow - Ingestion & Enrichment
Scope for R3 for Domain Projects:
Click to view domain projects individual scope!
Domain projects are related to services, data models and technology capabilities related to specific domains.
Domain Data Flow Services: These are projects related to ingestion (parsers, pre/post processing) and enrichment of domain specific data formats and data types:
- Generic Parser and Validation modules*
- Generic formats parsers (CSV, ASCII, JSON, …)
- Data Preparation scripts
- Parsers and agents for standard formats (LAS, Energistics, ...) and repositories (PPDM, ...)*
- Energistics parsers from Energistics
Scope for Layered Services Projects:
Click to view layered services projects scope!
- Data connectors for external data sources* from CVX
- Pending* TBD
- Global OSDU index federation (ala regions support) from SDU