Recommended Best Practice:
Sprint 12 Release: Updates to include support for widget Y and bug fixes for widget X
Not Recommended:
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 |
widget.service-SNAPSHOT-update-version |
|