Recommended Best Practice:
Sprint 12 Release: Updates to include support for widget Y and bug fixes for widget X
Sprint 12 Release: v3.0.1 updates
Note: The version number should be an output of the Sprint activity or Project interval, not decided ahead of time.
In the examples below, when QA finds a bug in v3.0.1, development needs to provide a v3.0.2 release for certification testing. Once v3.0.2 passes QA, it would be suitable to release to Production, bypassing any production release of v3.0.1.
A stated goal should be that code artifacts move unchanged from QA to Production, limiting the risk of an error creeping into Production during the release cycle.
Below is a sample of standard build jobs that should be created:
Recommended Build Jobs for a code project called “widget.service”:
|widget.service-SNAPSHOT||This is the standard build for development tasks|
|widget.service-SNAPSHOT-no-tests||A fast build that by-passes unit testing|
|widget.service-RELEASE-dry-run||A build that simulates a release, but does not perform the steps.
Should be run before the RELEASE builds in order to identify problems ahead of time.
|widget.service-RELEASE||The release build|