You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

Deliver Release Artifacts

StepActionResultsExamples
1Go to latest Gerrit merged review of repo and comment 'stage-release'
  • maven-stage Jenkins job is triggered
  • maven-docker-stage Jenkins job is triggered
  • Maven artifacts are published to Nexus 2 autorelease repository
  • Docker images are published to Nexus 3 registry
  • Change 118168
  • Job maven-stage-master 109
  • Job maven-docker-stage-master 109


2

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.

Set "tag_release: false" as we don't want to tag the repo at this step yet. This will be done at the next step.
This tag is NOT required for releases in H? (TBC)

Maven artifacts are published to maven release repository
  • Change 118174
  • Job cps-release-merge 1
3

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.

Note. Might need Timestamp tag too. See  CPS-264 - Getting issue details... STATUS

Docker image is published to docker release repository
  • Change 118178
  • Job cps-release-merge 2
4Update /kubernetes/cps/values.yaml in https://gerrit.onap.org/r/q/project:oom with new image versions

5

Prepare the next release by bumping and merging new version numbers:

  • In pom files, set to x.y.z-SNAPSHOT by running "mvn versions:set -DnewVersion=<snapshot version>"
  • In version.properties, set to x.y.z
Repo is ready for next release

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

  1. For R0, deliver releases artifacts from master branch as described in previous section.
  2. Create the release branch in Gerrit for the version you are about to release e.g. 'honolulu'
  3. Increase pom version numbers
    1. In master branch, increase minor version number (if not already done)
    2. In release branch, increase patch version number
  4. In release branch, update ".gitreview " (change "defaultbranch" value)
  5. 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

  1. 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)
    1. bug was reported by user of previous release (easy decision (smile))
    2. bug exposes behavior that was not in line with acceptance criteria for a user story that was delivered in previous release
  2. Make the fix and have it merged in master branch
    1. use minimal code to avoid merge/drop back issues
    2. specific test for bug fix should be included where possible
  3. Cherry pick the fix from master branch to release branch
    1. From Gerrit:
      1. Navigate to ... / Cherry Pick
      2. Fill the form with the release branch name (honolulu) in "Cherry Pick to branch" field and click "Cherry Pick"


    2. Using local branch (to resolve cherry-pick conflicts):
      1. Create local branch from honolulu  (create branch & switch to branch)
      2. Cherry-pick commit from master branch
      3. Resolve conflicts
      4. Continue cherry-pick (git cherry-pick --continue)
      5. git push origin HEAD:refs/for/honolulu (or git review)
  4. Review patch by peers as normal
    1. 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.
  5. 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
    1. Release Versioning Strategy (proposal for Honolulu)
    2. ONAP API Common Versioning Strategy (CVS) Guidelines
  6. Once the fix is in release branch, deliver releases artifacts from release branch as described in previous section.

References

  • No labels