Release Process

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.

 

Definition Of A Release.

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.

The Process.

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.

Step 1:

*

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

Step 2:

*

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

Step 3:

*

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.

Step 4:

*

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

Step 5:

*

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.

Step 6:

*

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.

Step 7:

*

QA shall perform any reasonable checks on the new release.

*

Customer Service shall perform any reasonable checks on the new release.