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