Deliver Release Artifacts
Step | Action | Results | Examples |
---|---|---|---|
1 | Update release notes | Release notes available on https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html | Change 123658 |
2 | Update read-the-docs copies of openapi documentation e.g. for CPS-Core: copy openapi.yaml /cps-rest/target/generated-sources/swagger/openapi.yaml → /docs/api/swagger/cps/openapi.yaml /cps-ncmp-rest/target/generated-sources/swagger/openapi.yaml → /docs/api/swagger/ncmp/openapi.yaml 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 | Go to latest Gerrit merged review of repo and comment 'stage-release' | ||
4 | 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) | Maven artifacts are published to maven release repository | |
5 | 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. Set "ref" to the (full) SHA of the git commit to be tagged. Take the latest built image, retag it without the timestamp : e.g. SO release file container_release_tag: '1.1.0' ... ... containers: - name: 'cps-and-ncmp' version: '1.1.0-SNAPSHOT-20210609T102555Z' | Docker image is published to docker release repository | |
6 | Prepare the next release by bumping and merging new version numbers:
| ||
7 | 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). |
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
- For R0, deliver releases artifacts from master branch as described in previous section.
- Create the release branch in Gerrit for the version you are about to release e.g. 'honolulu'
- Increase pom version numbers
- In master branch, increase minor version number (if not already done)
- In release branch, increase patch version number
- In release branch, update ".gitreview " (change "defaultbranch" value)
- 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
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.