...
Deliver Release Artifacts
Way of Working in Gerrit
- Ensure all commits are using related TOPIC (one topic for one artifact)
- Add "Release Process Step #' to each commit message (first line)
- Example:
https://gerrit.onap.org/r/q/topic:CPS-2220(NEW)
https://gerrit.onap.org/r/q/topic:%22CPS-728%22 (OLD)
Step | Scope | Action | Results | Examples | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Any Release | Update release notes Note. Check documentation configuration and release instructions on: Create documentation for an ONAP release (ONAP project teams) | Release notes available on https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html | ||||||||||
2 | Update read-the-docs copies of openapi documentation e.g. for CPS-Core:
For DMI-Plugin:
Note 1. Run Note 2. This step can be skipped if there are no OPEN API changes | Latest (amalgamated) openapi.yaml available in read-the-docs | |||||||||||
3 | For DMI Plugin and update any CPS Core release dependency, if needed:
| Changes | |||||||||||
4 | Go to latest Gerrit merged review of repo and comment 'stage-release' |
|
|
|
5 | Add and merge 'x.y.z.yaml' file to releases folder of the repository root. It describes the release and refers to maven-stage job previously ran. |
---|
Note: This step is ignored for CPS Temporal (no Maven artifact delivered) Note. this file should NOT contain ' |
tag_release |
=false |
' |
Maven artifacts are published to maven release repository |
|
6 |
---|
Add and merge 'x.y.z-container.yaml' file to releases folder of the repository root. It describes the release and refers to maven-docker-stage job previously ran. |
commit or the commit of the stage release Take the latest built image, retag it without the timestamp : e.g. SO release file
|
Docker image is published to docker release repository |
|
| |
7 | Prepare the next drop by bumping patch version (3rd digit)
|
---|
Prepare the next release by bumping and merging new version numbers:
In pom files,
|
|
|
Manage Release Branch
Prerequisites
- Code is frozen at M3, no new development is made after M3
- All testing (S3P, Integration Pair Wise) is completed at R0
Steps to create the release branch
...
8 | Once versions are bumped update the docker-compose file and update the latest images
| ||
---|---|---|---|
9 | Update https://gerrit.onap.org/r/q/project:oom with the release specific changes:
Before pushing changes to the release-specific OOM branch, it is required to push them to master first. If it can not be done, then specify a reason in the release-specific change (for example, image version number is branch specific and it is expected that it could be different in master branch and release branch). |
| |
10 | Only when Branching | Create the (previous) |
...
release branch in Gerrit for the version you are |
...
releasing e.g. ' |
...
istanbul' |
...
- In master branch, increase minor version number (if not already done)
- In release branch, increase patch version number
. Note : The branch is created in ONAP gerrit. After sync happens the branch is available in NORDIX for Step-13. | https://gerrit.onap.org/r/admin/repos/cps,branches | |
11 |
---|
...
In ci-management repo, configure new Jenkins jobs for the release branch by adding a new release stream to the project. e.g. https://gerrit.onap.org/r/c/ci-management/+/118868/1/jjb/cps/cps.yaml |
| ||
12 | On Master branch increase Minor version of Master branch (2nd digit)
|
| |
13 | On (previous) release (e.g. istanbul) branch:
|
|
Steps to Deliver Release Patches
- Decide with team if a bug should be dropped back to previous release or not, consider things like (use fix-version field in Jira to indicate this)
- bug was reported by user of previous release (easy decision
)
- bug exposes behavior that was not in line with acceptance criteria for a user story that was delivered in previous release
- bug was reported by user of previous release (easy decision
- Make the fix and have it merged in master branch
- use minimal code to avoid merge/drop back issues
- specific test for bug fix should be included where possible
- Cherry pick the fix from master branch to release branch
- From Gerrit:
- Navigate to ... / Cherry Pick
- Fill the form with the release branch name (honolulu) in "Cherry Pick to branch" field and click "Cherry Pick"
- Using local branch (to resolve cherry-pick conflicts):
- Create local branch from honolulu (create branch & switch to branch ?)
- Cherry-pick commit from master branch
- Resolve conflicts
- Continue cherry-pick (git cherry-pick --continue)
- git push origin HEAD:refs/for/honolulu (or git review)
- From Gerrit:
- Review patch by peers as normal
- Ensure that Gerrit merge requests both in master and release branches have the same Change-Id value (ex: https://gerrit.onap.org/r/q/Ia58a8dfcf427e373b24bb3be7436abf6abd55492). Then, related fixes can be easily filtered and clicking on the Change-Id from one change provides the list of all related ones.
- Ensure that Gerrit merge requests both in master and release branches have the same Change-Id value (ex: https://gerrit.onap.org/r/q/Ia58a8dfcf427e373b24bb3be7436abf6abd55492). Then, related fixes can be easily filtered and clicking on the Change-Id from one change provides the list of all related ones.
- Update Release version in a separate commit if and when required
A few bugs can be combined in one patch.
Release notes doc should be updated too
Typically only the 'patch' number (last digit) should be increased. See also - Once the fix is in release branch, deliver releases artifacts from release branch as described in previous section.
Preparing for third party (stakeholder) testing of specific features before general (onap) release
- Ensure a Jira is created and shared with stakeholder to track the required change
- CPS Team might create dependent (blocking) Jira's link to the main Jira as required
- Common Acceptance criteria:
- latest RTD Design docs get update with relevant APIs (e.g. https://docs.onap.org/projects/onap-cps/en/latest/design.html)
- latest RTD Release Note (new snapshot section) wil be updated with the delivered Jira (from step 1) (similar to https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html#version-2-0-1)
- CSIT test wil be updated/added to cover new functionality
- Demo to stakeholder (this is really the best sign it is -almost- done to the stakeholder)
- Jira can be closed (stakeholder can subscribe to notifications about this)
- Stakeholder team can take source and using their own preferred process build new images for testing
This does NOT include:
- Version updates ie. CPS will only update version as is required for the ONAP release process
- (Docker) image building