Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Updated documentation to incorporate CITR & Semantic Release #17327

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,3 +12,8 @@ An [Eclipse Adoptium](https://adoptium.net/) build of the Java **21.0.1** JDK is
- [Java Style Guide](hedera-java-style-guide.md)
- [Maintainers Guide](maintainers-guide.md)
- [Glossary](glossary.md)

## Continuous Integration Test & Release

- [Continuous Integration Test Overview and Best Practices](continuous-integration-testing-overview.md)
- [Release Process](continuous-release.md)
2 changes: 1 addition & 1 deletion docs/continuous-integration-testing-overview.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Continuous Integration Test Overview and Best Practices
# `Continuous Integration Test Overview and Best Practices`

The series of workflows that make up the Continuous Integration Testing and Release (CITR) process are intended
to drive rapid development and release of code within the Hedera Hashgraph services and platform codebase. This
Expand Down
85 changes: 85 additions & 0 deletions docs/continuous-release.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# Continuous Release Process

## Background

The Release Process within Hedera-Services will be changing beginning with Release 0.59. This will be the first step in
migrating to a fully automated release process with CITR.

### Historical Process

The release process within hedera-services has been using a release branching strategy that follows
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The release process within hedera-services has been using a release branching strategy that follows
The release process within Hedera-Services has been using a release branching strategy that follows

a set development cycle
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
a set development cycle
a set development cycle:


| Stage | Duration |
|-------------------------------------|----------|
| Planning | 12d |
| Development | 33d |
| **milestone** Create release branch | 0d |
| Bugs & Fix | 12d |
| **milestone** Deploy to preview net | 12d |
| **milestone** Create alpha tag | 0d |
| **milestone** Deploy to test net | 1d |
| Perform migration testing | 22d |
| **milestone** Deploy to main net | 7d |
| Release Retrospective | 1d |

Each release takes approximately one calendar quarter to complete (from planning to retrospective)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Each release takes approximately one calendar quarter to complete (from planning to retrospective)
Each release takes approximately one calendar quarter to complete (from planning to retrospective).


### Relevant CITR Background

The continuous integration test and release process has been being executed within Hedera-Services since Q3-2023.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The continuous integration test and release process has been being executed within Hedera-Services since Q3-2023.
The continuous integration test and release (CITR) process has been being executed within Hedera-Services since Q3-2024.

As part of this process there is a minimal acceptable test suite (MATS) that runs against every pull request. Further,
there is an extended test suite (XTS) that runs on each commit to the `default branch` in Hedera-Services (`main`).
After MATS and XTS complete successfully the commit is tagged with a **build** tag (`build-XXXXX`). This tag is the
crux of the new release process.

## CITR Release Process

The release process will be changing in the following areas beginning with `Release 0.59`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The release process will be changing in the following areas beginning with `Release 0.59`
The release process will be changing in the following areas beginning with `Release 0.59`:


| Stage | Duration |
|---------------------------------------------------------|----------|
| Planning | 12d |
| Development | 33d |
| [NEW] **milestone** Select candidate commit for release | 0d |
| [NEW] Run the `zxf-trigger-semantic-release` workflow | 0d |
| [DEL] ~~**milestone** Create release branch~~ | ~~0d~~ |
| [DEL] ~~Bugs & Fix~~ | ~~12d~~ |
| **milestone** Deploy to preview net | 12d |
| [DEL] ~~**milestone** Create alpha tag~~ | ~~0d~~ |
| **milestone** Deploy to test net | 1d |
| Perform migration testing | 22d |
| **milestone** Deploy to main net | 7d |
| Release Retrospective | 1d |

### Selecting a build candidate

The XTS workflow will tag a commit with a `build-xxxxx` tag upon successful completion.

The release managers will pull a release candidate from this set of tags.

The release managers will run `zxf-trigger-semantic-release`, specifying the build number, in order to create the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The release managers will run `zxf-trigger-semantic-release`, specifying the build number, in order to create the
The release managers will run the workflow `zxf-trigger-semantic-release`, specifying the build number, in order to create the

release tagged commit (v0.59.0 or similar)

**Note:** The build number is actual number described in the build tag. The tag `build-00025` has a build number `25`.

This release tag (v0.59.0 or similar) is the tag that will be deployed to preview-net, test-net, and main-net.

If bugs are discovered in the build during release testing we can run `zxf-trigger-semantic-release` on a new build
candidate, as determined by the release managers, and select `create patch` when running the workflow. This will
generate a patch version release with the new build (v0.59.1 or similar) which can then run through the various
test/release networks.

## Impacts for Developers

Beginning with release 0.59:

- The following items will be restricted:
- Creating release branches in `hedera-services` (like release/0.59)
- Creating versioned tags like (v0.59.*)
- The following workflows will be added:
- `zxf-trigger-semantic-release` - Generate a release tag given an XTS passing build id
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- `zxf-trigger-semantic-release` - Generate a release tag given an XTS passing build id
- `zxf-trigger-semantic-release` - Generate a release tag given an XTS passing build id.

- `zxf-version-roll` - Roll the version specified in `version.txt` for the current development cycle on the default
branch.
- Release management will need to choose a build candidate from a list of associated builds (recommendation will be the
latest `build-xxxxx` tag)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
latest `build-xxxxx` tag)
latest `build-xxxxx` tag).

8 changes: 8 additions & 0 deletions docs/maintainers-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,6 +98,14 @@ The DevOps-CI team will handle the following:
- Will handle production releases
- Note: no release branch will be created

### Github CI Workflow Naming Conventions

- node-* and platform-* prefix is a legacy carryover because node repo and platform repo were merged together.
- flow-* is a standalone workflow that can be executed by a user (should have a workflow-dispatch trigger). It can also be a PR target. Anything the user interacts with starts with flow.
- z* was to force everything to sort to the bottom of the view in the Actions tab of github. We can now pin these.
- xf means a workflow that can be trigger by other means (workflow_run or workflow_dispatch) but are not user facing.
- xcron is a cron job kickoff script.

### User Stories

#### As a developer, I would like to create a branch to work on the feature for the upcoming release
Expand Down
Loading