-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #662 from eclipse-tractusx/572_align_release_infos…
…_across_repos add initial content for release consolidation
- Loading branch information
Showing
5 changed files
with
287 additions
and
79 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,66 @@ | ||
| # Roadmap and Release 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 product). A label for each involved product 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`. | ||
| - **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 products 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 products are discovered and respective `Labels` are added. 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. | ||
| The fully refined status "backlog" is the entry point for our "open planning" ceremony. During "open planning" a milestone is set for each feature. This represents a commitment, given by the open source community to finalize the feature in due time. | ||
| 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. | ||
|
|
||
|
|
||
| ## Issue hierarchy (WIP) | ||
|
|
||
| @stephanbcbauer to formulate details | ||
| => detailed features are planned and executed within the repositories of the respective product. Summary features are planned and managed on "SIG release" level... | ||
|
|
||
|
|
||
| ## Planning product 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 product team to break these issues down to their product repositories/projects. | ||
| When doing so, make sure you link to the overarching issue in your product issue description. | ||
|
|
||
| See [product release](product_release.md), for information about singular product releases. | ||
|
|
||
| See [Tractus-X release](tractus-x-release.md), for our overarching release strategy. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,76 @@ | ||
| # Product Release | ||
|
|
||
| ## Intro | ||
|
|
||
| Product releases are done by creating a GitHub release. Every release is following the [Semantic Versioning](https://semver.org/) pattern and must be 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. | ||
|
|
||
| Tractus-X products do follow their own release process. They are individually developed and therefore no strict workflow is enforced. To ensure a consistent view on releases, the following aspects should still be met: | ||
| - A CHANGELOG.md file, that follows keep a changelog recommendations is maintained and updated with descriptions for the current product release | ||
| - Links to GitHub external artifacts (i.e. mvncentral or Docker Hub) are referenced | ||
| - GitHub releases are used to publish artifacts | ||
| - Git tags are added accordingly (usually done automatically) | ||
| - The changelog content of the current release is documented in the GitHub release | ||
| - Helm charts are released into the aligned helm chart repository | ||
|
|
||
| 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 assurance is the same across all of them. | ||
|
|
||
| The release contents for individual products are planned in the [open refinement and planning](./open-refinement-and-planning.md) sessions. These sessions define the scope for all dataspace products, and therefore paint a clear picture of enhancements necessary for every single product. The product teams themselves 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). | ||
|
|
||
| Every product needs to adhere to the [Tractus-X release guidelines (TRGs)](https://eclipse-tractusx.github.io/docs/release). | ||
| > **HINT:** | ||
| > this is in addition to the integration- and unit-test suites the teams maintain | ||
| > Take special care about legal requirements defined in TRG 7. They **must** be adhered to on every PR. | ||
| 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. | ||
|
|
||
| Integration tests are performed by maintaining a Product Umbrella Chart, that deploys all relevant dataspace products to spin up an artificial dataspace based on Tractus-X products. | ||
| 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. | ||
|
|
||
| Products **must** opt-in to the process in order to be included in a Tractus-X release. | ||
| 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 | ||
|
|
||
| - GitHub release (Changelog + Sourcecode) | ||
|
|
||
| Most Tractus-X products are software products. In these cases, packaging the sourcecode together with a list of used dependencies is a good starting point and should be included as artifact of a release in almost any case. | ||
|
|
||
| - Container images | ||
|
|
||
| All container images provided by Tractus-X are only provided for development, testing etc. without any guarantee on license or security. Feel free to use them on your own risk, all images can be build by yourself through provided Dockerfiles. | ||
|
|
||
| - Product Umbrella Helm Chart | ||
|
|
||
| Applications developed in the Tractus-X context typically provide a Helm chart for easy deployment on kubernetes. | ||
| To add a Helm chart as a release artifact it has to be packaged. There are multiple tools, that help packaging charts. We recommend using the chart-releaser-action GitHub action though, since together with activated GitHub pages, it can transform your repository to function as Helm chart repository on its own. | ||
|
|
||
| Additionally, Tractus-X offers a central Helm chart repository. It supports two channels for released Helm charts - dev and stable. | ||
|
|
||
| The **dev-channel** is used to publish the most recently released charts. It is updated nightly and automatically pulls in the latest chart releases of the [eclipse-tractusx](https://github.com/eclipse-tractusx) GitHub organization. | ||
|
|
||
| The **stable-channel** is used by the release management group, to publish all helm charts, that were successfully tested and included in an overarching release. This means, that the stable channel only includes specific versions of product charts, that are tested to the best of our knowledge to work together with other stable charts. | ||
|
|
||
| Patching strategy | ||
| tbd | ||
|
|
||
| Helm Repository | ||
| For information about using the Tractus-X Helm repository, please refer to the charts repository. | ||
|
|
||
|
|
||
| ## Versioning | ||
|
|
||
| - [Semantic Versioning](https://semver.org/) | ||
|
|
||
|
|
||
| ## Quality Assurance | ||
|
|
||
| - Defined in [Tractus-X Release Guidelines / TRGs](https://eclipse-tractusx.github.io/docs/release) | ||
| - Responsibility of every contributor | ||
| - Currently still verified in a Quality Gate process. TBD if this process will continue. |
Oops, something went wrong.