Skip to content

Release Process

Jump to bottom Edit New page
Andrew Fiedler edited this page Apr 9, 2020 · 11 revisions

Monthly Releases

DDF has gone to monthly releases with no formal voting from the DDF PMC.

How to create a DDF Release

Prereqs / Info:

Required tools

  • Use Maven >= 3.1.0
  • Use git client >= 1.8

Sample Versioning

SNAPSHOT RELEASE
1.0.0-SNAPSHOT 1.0.0
1.1.0-SNAPSHOT 1.1.0

Steps

  1. Create new DDF Branch "We release off the branch so that there are no concerns about another PR being merged to master. This is also ensures that the new branch is more controlled and saves the step of having to announcing pausing merging into master."
  2. Minor and Major Releases (for patch releases such as 2.22.1, skip to the next section)
  • Create the new branch git co -b 2.22.x
  • Set a new development version on the branch mvn versions:set Enter the new version to set 2.22.0:
  • Push the new branch git push origin 2.22.x
  1. Release from the DDF Pipeline job
  • Branch - This is the branch that should be released. For DDF this should always be a ..x branch. Ex. 2.21.x
  • nextDevVersion - Under normal release circumstances this field should not need to be populated as the build will just increment the version bug number by 1. Ex 2.11.0-SNAPSHOT will become 2.11.1-SNAPSHOT
  • releaseType - There are three different types of release, Build, RC, and Release. See the Release Types section for the differences.  
  • notesUrl - URL to the Release Notes
  • skipTests - This option if checked will skip all the unit tests, itests, and static analysis when performing the release. Depending on how finicky the CI environment is at the time it might be necessary to check this option.
  • testRun - If this option is selected all the normal release processing will occur but nothing will be push to the repo and no artifacts will be deployed. Select this option if you just want to verify the release process is working.
  • artifactRedeploy - It is only used in the case that you have to "redeploy" because the "deploy" phase fails while deploying artifacts. This is a reminder to ensure you properly enable this capability in Nexus.
  • Example
  1. Monitor the DDF Release job
  1. After the release job completes (at least the Push Commits/Tags stage when the release tag is created), the new branch can be created and pushed. This represents the new branch that will be used to patch this release.
  2. Set a new version on DDF Master
  • Check out the tag cd /DDF-Fork git co master
  • Set new development version on master git co -b ddf-update-version mvn versions:set Enter the new version to set 2.22.0: 2.23.0-SNAPSHOT
  • Push the new branch git push origin ddf-update-version
  • Create a Pull request for this change and comment build now just to verify the build is successful. For example: https://github.com/codice/ddf/pull/5606

6 Update the DDF Documentation

  • Confluence Release Notes (can be done while the pipeline runs) - Create or update the existing release notes page for the released version under https://codice.atlassian.net/wiki/spaces/DDF/pages/71275152/Release+Notes. In the past, creating a new Release Notes pages has been accomplished by copying the previous Release Notes page and updating the version numbers.

  • http://github.io/ Page (Normally handled by Rick, after the release) http://codice.org/ddf/Documentation-versions.html serves the DDF documentation for the most current release. To update these for a DDF release, follow these steps:

  • Checkout the gh-pages branch of DDF. 

  • Download and unzip the docs-export.zip file from Nexus once available.

  • Replace the html and pdf files in the docs folder of the gh-pages branch.

  • Commit latest versions create a PR for the new files.

  1. Github Release (needs to be done by a committer, after the release)

Go to the Github Release Area and draft a new release.

Manually Creating the Release

//checkout a clean copy of the repository
git checkout https://github.com/codice/ddf.git

//change directory to repo
cd ddf
 
//release from the desired branch (e.g. 2.10.x). In this example master is used
git checkout 2.10.x
 
//verify no files are checked out
git status 
 
//verify the latest 
git pull --rebase origin
 
//version according to versioning guidance
// if releasing master, next development version increments minor version
// if from a minor branch, next development version increments patch version
mvn release:prepare -Prelease -Dmaven.repo.local=/clean/repo/location
 
//verify new tag name
git tag 
 
//push the new branch (in this example master is used) and tag
git push origin 2.10.x ddf-2.10.0
 
//Clean release files
mvn release:clean -Dmaven.repo.local=/clean/repo/location
 
//check out the new tag that was created
git checkout ddf-2.10.0
 
//Deploy the artifacts into the Codice Nexus
//Verify the appropriate settings file is used to deploy to Codice Nexus
mvn deploy -Prelease -DskipStatic=true -DskipTests=true -Dmaven.repo.local=/clean/repo/location
 
//reminder to not stay in the tag
//check out the branch again
git checkout master
 
 

Manually Deploying to Nexus

The purpose of this section is to provide instructions on how to deploy to the Codice Nexus in the event of a automated release deployment failing.

//check out the new tag that was created
git checkout ddf-2.21.0
 
//Deploy the artifacts into the Codice Nexus
//Verify the appropriate settings file is used to deploy to Codice Nexus
mvn deploy -Prelease -DskipStatic=true -DskipTests=true

Release Checklist

Jira (https://codice.atlassian.net/projects/DDF?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=unreleased)

  • Make sure all tickets associated with the release are closed or moved to a later release

Setting the DDF version

Use the maven version set command to set the DDF version in the pom files:  http://www.mojohaus.org/versions-maven-plugin/set-mojo.html.

mvn versions:set -DnewVersion=2.10
  • Release the current version
  • Create the next version for that branch
Add a custom footer
Add a custom sidebar
Clone this wiki locally