Acceptance Criteria for Release

Overview

Documents acceptance criteria that must be met to perform a maven release and conclude a development cycle.

Criteria

Consider using the following as a release acceptance criteria checklist:

• Build succesfully from a blank environment.
• Log in as a "new" user (e.g. UTS)
• All Unit tests must pass (e.g. a stock-build of the top-level project works without errors).
• The load.bat/csh script must successfully load the dev environment into a database.
• The integration tests must pass running against a database/server containing the stock dev environment.
• The mojo integration tests must pass running against an empty test database.
• The "entire" snapshot/full SNOMED loads must complete without running out of memory on a machine with 8GB of RAM in reasonable time.
• Deployment server UI works.
• Deployment server Swagger API loads.
• Documentation is updated (as needed)
• TODO items are converted into new tickets and removed.
• All "system.out.println" statements are moved.
• Code is import-organized and formatted.

Performing a Maven Release

Maven release is handled with jgitflow.  There are two parts

Starting a release involves passing the release version, the next dev version, and a flag about auto versioning submodules.

cd <top level project>
mvn jgitflow:release-start -DautoVersionSubmodules=true -DreleaseVersion=0.9.0.RELEASE -DdevelopmentVersion=1.0.0-SNAPSHOT -DpushReleases=true

This can also be done in Eclipse like this:

If all goes well, the next step is to finish the release, like this:

# release start must already have been run
cd <top level project>
mvn jgitflow:release-finish -DautoVersionSubmodules=true -DpushReleases=true

This also can be done in Eclipse as follows:

The end result of the release process is

• A new branch named after the release (with the release version) pushed to upstream origin
• An updated development version set for all modules.

References/Links

• n/a