Introduction
This
document specifies the steps to be taken, and the responsible departments when
a new software release is to be made operational. This document:
|
demonstrates to interested
parties that the process is well controlled and will ensure successful
transition from development through to operation |
|
enables effective
control, and successful implementation against well defined and tested
process steps. |
The
document is controlled by the Vice President of Engineering [TBC}. The Director
of Operations and Director of QA are responsible for the execution of the
actual release steps which fall within their own areas of responsibility in
accordance with this process.
A
release is all software, installation scripts, data and documentation
associated with changes that have been implemented to fulfill an agreed set of
requirements according to the User Requirements Document
(URD) and System Response Documents (SRD), or
associated with a release which addresses known errors within the previously
operational system. In either case, the features and their behaviour will be
documented well before this process is initiated, and these features/behaviours
will only be referenced during this process.
The
appropriate development group will have reached agreement with their customer
(typically the marketing department) as a direct result of the URD/SRD process,
and associated software, installation scripts data and documentation will have
been generated accordingly. The full release information, however, is not
available until the complete release process has been successfully executed.
All groups involved are expected to provide relevant documentation as they
fulfil their tasks. This documentation will be available on the company
intranet, and will be available to all involved parties.
All
of the following steps will be executed in sequence. There are situations that
will require some step or steps to be repeated. Under no circumstances will a
step be executed until all previous steps have been successfully completed.
|
Development shall define the
content of pending releases. This content shall in all cases refer to already
defined URD/SRD features,
and/or already known errors which are to be corrected. |
|
Development shall provide
the expected schedule for readiness of release to QA to allow QA to prepare
in advance for their work. |
|
Development shall create
a unique ID for each release, and open an associated area on the company
intranet where all associated documentation will be placed. |
|
A meeting will be held
between Development and QA to ensure that release implications are
understood. |
|
QA shall develop and
publish the associated Test Plan |
|
QA shall provide the expected
schedule of releases to Operations and Customer Service, in accordance with
the expected deliveries from development |
|
Development shall inform
QA when a release is ready. |
|
They shall also inform QA
of any modifications to the expected release in the form of URD/SRD features,
or errors that have not been included in the release, or have been added or
have a different behaviour than originally expected. All of this information
shall be in written form, and be available in the defined documentation area. |
|
Development shall provide
QA with any additional/changed documentation, including install
documentation. |
|
A meeting shall be held
between Development and QA to ensure that release implications are
understood. |
|
QA shall inform
Operations and Customer Service if there is a change in the expected release
schedule |
|
QA shall check that all
of the necessary documentation, software etc is available. |
|
QA shall check all
documentation for quality, and accuracy. |
|
QA shall perform all
regression testing needed |
|
QA shall perform all
additional testing for changed or added features. |
|
When ALL of step 3 items are
accepted by QA, step 5 will be instigated |
|
If any of step 3 items
are not accepted, then a meeting shall be held between Development and QA to
ensure that release implications are understood. |
|
If any of step 3 items
are not accepted, then steps 2 and 3 will be repeated until full acceptance |
|
QA shall approve and
publish release documentation. This will include all feature and install
documentation. |
|
QA shall place the
release in the QA transfer area. |
|
QA shall inform
Operations & Customer Service that the release is available. |
|
Operations shall ensure
that all the information and release material is available. |
|
Operations shall perform
any checks they feel are necessary |
|
Operations shall publish
the live release schedule to Customer Service, Development and QA. There
shall be a deadline set for 'objections'. |
|
If objections are
received, a new schedule shall be set, and the process repeated. |
|
Operations shall perform
the implementation of the release to the live environment from the QA
transfer area at the scheduled time, and confirm to Customer Service,
Development, and QA. |
|
Operations shall publish a
release note to the release documentation area. |
|
QA shall perform any
reasonable checks on the new release. |
|
Customer Service shall
perform any reasonable checks on the new release. |