diff --git a/README.md b/README.md index ae02d187..5464dca1 100644 --- a/README.md +++ b/README.md @@ -6,86 +6,15 @@ If you are interested in the current state of planning, have a look at our [Rele ## The planning and roadmap process -We follow a coordinated approach to plan improvements of Eclipse Tractus-X. see also [Open Planning and Refinement](docs/open-refinement-and-planning.md). +For detailed process descriptions, see [the planning documentation](./docs/planning.md). -While every repository in the [eclipse-tractusx](https://github.com/eclipse-tractusx) GitHub organization -has its own issue management, the [Release Planning Board](https://github.com/orgs/eclipse-tractusx/projects/26) -is used to align the overarching Tractus-X releases. +## Release -### How can I get involved +In Tractus-X, we differentiate two different types of releases. -In case you experienced a bug, unexpected behaviour, or you want to propose enhancements to Eclipse Tractus-X, -feel free to use one of the provided [issue templates](https://github.com/eclipse-tractusx/sig-release/issues/new/choose) and describe your request. -Please be aware, that not every feature request can be integrated and that we also cannot treat every issue with the highest priority. - -Every Release planning will be kicked off by two public alignment sessions. The dates and further details will be shared via -[tractusx-dev](https://accounts.eclipse.org/mailing-list/tractusx-dev) mailing list. -In addition to that, you can also find public meetings and info about how to join on our -[Open Meetings](https://eclipse-tractusx.github.io/community/open-meetings) community page. -Issues or bug reports, that should be discussed in these meetings, have to be opened prior to the meeting via -our [issue templates](https://github.com/eclipse-tractusx/sig-release/issues/new/choose). - -### What can I expect - -We really welcome every contribution. Every Bug report and feature proposal takes time to prepare, -is valuable to our project, and we very much appreciate this input. -We are giving our best to give a first feedback in one week. -If we should miss that, please stick with us and just use the commenting function to remind us of the issue. - -### Issue structure - -Our issues do have important properties, that enable our planning process. These are: - -- __Labels:__ We use them to indicate the involved teams (kit or foss component). A label for each involved component is added to an issue -- __Issue Type:__ To separate between bugs, feature requests and release criterias, we use a custom field `Issue Type` -- __Milestone:__ Every Tractus-X release is represented by a `Milestone`. You can use this field to get a rough idea about the ETA -- __Status:__ The status field is used to integrate the progress of an issue - -### Issue statuses - -The following statuses are defined: - -- __Inbox:__ This is the initial status of all issues. It indicates, that involved components have to be identified and additional information gathered -- __Backlog:__ If enough information is gathered, and we agreed to work on the issue, it is set from `Inbox` to `Backlog` to indicate it is ready for timeline planning -- __Work in Progress:__ The issue is actively been worked on. -- __Done:__ All relevant parts have been implemented and released - -### Issue process - -Every new feature proposal or bug report will be handled as issue in status `Inbox` initially. The alignment meetings are used to discuss the purpose and impact of the current issues. -While in `Inbox` status, the involved components are discovered and respective `Labels` are added. If already possible, a desired `Milestone` can be set. -Additionally, an `Assignee` is selected, who will coordinate efforts to solve the issue. - -After these details are clarified, an issue is moved to `Backlog` to open it for detailed timeline planning. In this status, discussions about a fitting `Iteration` is held. - -As soon as actual work is started in the selected iteration, the issue is set to `Work in Progress`. This is especially helpful on our project milestone views to get an overview of the release progress. - -The final status `Done` is set, as soon as all relevant implementations are done, tested and released. This has to be achieved for every change in every involved component. - -### Planning component changes - -While the [Release Planning Board](https://github.com/orgs/eclipse-tractusx/projects/26) is used to coordinate overarching feature and bug requests, -we encourage every component team to break these issues down to their component repositories/projects. -When doing so, make sure you link to the overarching issue in your component issue description. - -## Release Management Acceptance Criteria - -The release participation can be initiated by creating issues for the acceptance criteria check from the Issue templates. -Each release the templates for the acceptance criteria will be renewed. There are two paths for processing the acceptance criteria for an application team to participate in a release. - -### The Release Happy Path for the Acceptance Criteria - -The three process steps to get to the status you need to pass the Q-Gate are shown in the happy path process flow. - -Each acceptance criteria issue in GitHub contains a note with the prime contacts so that it is clear who is the assigned expert or release manager. - -![Happy Path](docs/static/releasemanagement-acceptance-happy-path.svg) - -### The other Release Path - -If the evidence is not sufficient so that the criterium can not be accepted in the quality gate (QG), obligations for the product team will be defined to make a reassessment. -![The other Path](docs/static/releasemanagement-acceptance-other-path.svg) +See [product release](./docs/product_release.md), for information about singular product releases. +See [Tractus-X release](./docs/tractus-x-release.md), for our overarching release strategy. ## Contact @@ -96,5 +25,5 @@ If the evidence is not sufficient so that the criterium can not be accepted in t This work is licensed under the [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). - SPDX-License-Identifier: Apache-2.0 -- SPDX-FileCopyrightText: 2022,2023 Contributors to the Eclipse Foundation +- SPDX-FileCopyrightText: 2022 Contributors to the Eclipse Foundation - Source URL: https://github.com/eclipse-tractusx/sig-release diff --git a/docs/planning.md b/docs/planning.md new file mode 100644 index 00000000..ef862be8 --- /dev/null +++ b/docs/planning.md @@ -0,0 +1,81 @@ +# Release and Roadmap Process + +We follow a coordinated approach to plan improvements of Eclipse Tractus-X. See also [Open Planning and Refinement](open-refinement-and-planning.md). + +While every repository in the [eclipse-tractusx](https://github.com/eclipse-tractusx) GitHub organization +has its own issue management, the [Release Planning Board](https://github.com/orgs/eclipse-tractusx/projects/26) +is used to align the overarching Tractus-X releases. + +### How can I get involved + +In case you experienced a bug, unexpected behaviour, or you want to propose enhancements to Eclipse Tractus-X, +feel free to use one of the provided [issue templates](https://github.com/eclipse-tractusx/sig-release/issues/new/choose) and describe your request. +Please be aware, that not every feature request can be integrated and that we also cannot treat every issue with the highest priority. + +Every Release planning will be kicked off by two public alignment sessions. The dates and further details will be shared via +[tractusx-dev](https://accounts.eclipse.org/mailing-list/tractusx-dev) mailing list. +In addition to that, you can also find public meetings and info about how to join on our +[Open Meetings](https://eclipse-tractusx.github.io/community/open-meetings) community page. +Issues or bug reports, that should be discussed in these meetings, have to be opened prior to the meeting via +our [issue templates](https://github.com/eclipse-tractusx/sig-release/issues/new/choose). + +### What can I expect + +We really welcome every contribution. Every Bug report and feature proposal takes time to prepare, +is valuable to our project, and we very much appreciate this input. +We are giving our best to give a first feedback in one week. +If we should miss that, please stick with us and just use the commenting function to remind us of the issue. + +### Issue structure + +Our issues do have important properties, that enable our planning process. These are: + +- __Labels:__ We use them to indicate the involved teams (kit or foss component). A label for each involved component is added to an issue +- __Issue Type:__ To separate between bugs, feature requests and release criteria, we use a custom field `Issue Type` +- __Milestone:__ Every Tractus-X release is represented by a `Milestone`. You can use this field to get a rough idea about the ETA +- __Status:__ The status field is used to integrate the progress of an issue + +### Issue statuses + +The following statuses are defined: + +- __Inbox:__ This is the initial status of all issues. It indicates, that involved components have to be identified and additional information gathered +- __Backlog:__ If enough information is gathered, and we agreed to work on the issue, it is set from `Inbox` to `Backlog` to indicate it is ready for timeline planning +- __Work in Progress:__ The issue is actively being worked on. +- __Done:__ All relevant parts have been implemented and released + +### Issue process + +Every new feature proposal or bug report will be handled as issue in status `Inbox` initially. The alignment meetings are used to discuss the purpose and impact of the current issues. +While in `Inbox` status, the involved components are discovered and respective `Labels` are added. If already possible, a desired `Milestone` can be set. +Additionally, an `Assignee` is selected, who will coordinate efforts to solve the issue. + +After these details are clarified, an issue is moved to `Backlog` to open it for detailed timeline planning. In this status, discussions about a fitting `Iteration` is held. + +As soon as actual work is started in the selected iteration, the issue is set to `Work in Progress`. This is especially helpful on our project milestone views to get an overview of the release progress. + +The final status `Done` is set, as soon as all relevant implementations are done, tested and released. This has to be achieved for every change in every involved component. + +### Planning component changes + +While the [Release Planning Board](https://github.com/orgs/eclipse-tractusx/projects/26) is used to coordinate overarching feature and bug requests, +we encourage every component team to break these issues down to their component repositories/projects. +When doing so, make sure you link to the overarching issue in your component issue description. + +## Release Management Acceptance Criteria + +The release participation can be initiated by creating issues for the acceptance criteria check from the Issue templates. +Each release the templates for the acceptance criteria will be renewed. There are two paths for processing the acceptance criteria for an application team to participate in a release. + +### The Release Happy Path for the Acceptance Criteria + +The three process steps to get to the status you need to pass the Q-Gate are shown in the happy path process flow. + +Each acceptance criteria issue in GitHub contains a note with the prime contacts so that it is clear who is the assigned expert or release manager. + +![Happy Path](docs/static/releasemanagement-acceptance-happy-path.svg) + +### The other Release Path + +If the evidence is not sufficient so that the criterium can not be accepted in the quality gate (QG), obligations for the product team will be defined to make a reassessment. +![The other Path](docs/static/releasemanagement-acceptance-other-path.svg) diff --git a/docs/product_release.md b/docs/product_release.md new file mode 100644 index 00000000..9246f5ee --- /dev/null +++ b/docs/product_release.md @@ -0,0 +1,44 @@ +# Product Release + +Tractus-X products do follow their own release process. Please check the leading product repositories for details. +Independent of the technical details of product release processes, the released artifacts and minimum level of quality ensurance +is the same across all of them. + +The release contents for individual products are are planned in the [open refinement and planning](./open-refinement-and-planning.md) sessions. +These sessions define the scope for all dataspace components, but therefore paint a clear picture of enhancements necessary for every single product. +The product teams themselfes are then responsible to define fine-grained task breakdowns as suiting their own needs. + +> __HINT:__ +> If product enhancements contribute to an overarching dataspace feature, please link the dataspace feature defined in `sig-release` in your product issue. +> These links can be done in either the description or any comment on your issue. Use `eclipse-tractusx/sig-release#issue-number` + +Once planning activities for a certain iteration are completed, the implementation phase is starting and product teams can coordinate, where necessary +through our [communication channels](https://eclipse-tractusx.github.io/docs/oss/getting-started#communication-channels). + +Integration tests are performed by maintaining an umbrella Chart, that deploys all relevant dataspace components to spin up an artificial dataspace based on Tractus-X components. +There is a dedicated repository [eclipse-tractusx/tractus-x-umbrella](https://github.com/eclipse-tractusx/tractus-x-umbrella), that is maintained collectively to reflect the latest product release versions. + +Additional to the integration- and unit-test suites the teams maintain, every product also needs to adhere to the [Tractus-X release guidelines (TRGs)](https://eclipse-tractusx.github.io/docs/release). +Compliance to these guidelines __should__ be verified on every PR, but __must__ be complied with, as soon as a new product version is planned to be included in the Tractus-X release. + +> __HINT:__ +> Take special care about legal requirements defined in TRG 7. They __must__ be adhered to on every PR. + +Product releases are done by creating a GitHub release. Every release is following the [semantic versioning](https://semver.org/) pattern and marked in the git history via tag. +If suitable for the product teams development process, release candidate versions can help to provide early previews of a product for integration testing. + +## Artifacts + +- GitHub release (Changelog + Sourcecode) +- Container images +- Helm Chart + +## Versioning + +- Semantic Versioning + +## Quality Assurance + +- Defined in TRGs +- Responsibility of every contributor +- (Additonally verified in quality gate process. TBD, if kept after consortia) diff --git a/docs/tractus-x-release.md b/docs/tractus-x-release.md new file mode 100644 index 00000000..063b172b --- /dev/null +++ b/docs/tractus-x-release.md @@ -0,0 +1,38 @@ +# Tractus-X Release + +The Tractus-X release process aims to ensure compatibility of Tractus-X components and defines +and defines common quality criteria. Releases are initiated on a quarterly basis. +The desired enhancement of the dataspace functionality is planned in the [open refinement and planning](open-refinement-and-planning.md) sessions. +Past release documention can be found in [eclipse-tractusx/tractus-x-release](https://github.com/eclipse-tractusx/tractus-x-release). + +To be included in a Tractus-X release, products __must__ opt-in to the process. +This is done by requesting a release review 4 weeks prior to the planned release date, using the "Product Release Check" [issue template](https://github.com/eclipse-tractusx/sig-release/issues/new/choose). + + + +## Artifacts + +- Changelog (overarching features) +- Umbrella Helm Chart(s) +- Overarching architecture documentation (if available) + +## Versioning + +- Calendar versioning + +## Process + + +- Prior to release, a Tractus-X umbrella Chart release candidate branch is created +- Producs issue PRs with their release candidate + +### Quality Assurance + +- User Journey tests (e2e) defined in e2e-testing repo +- User Journey tests automatically executed via `helm test` (nightly + on every product rc PR)