This section describes how to implement a basic release management process
and the tools required to support it.
|
|
The release policy is something that should be determined locally. However, in
order to implement Release Management effectively, we recommend the following
initial policy:
- Create and follow a standard process for installing and testing new user
hardware and software.
- Create and follow a standard procedure for each different hardware and
software service.
- Store all software centrally.
|
|
You should make it a policy to create and develop a definitive software library to
help you manage your software licence allocation and ensure that the correct
versions of software are installed. It also saves time searching for original disks
when you are in a hurry to install something. It is about tidiness as much as
anything else.
|
|
Always retain original software - at least one set of each version - in a central library.
|
Storage
|
Diskette or CD boxes provide adequate storage
for original software.
|
|
Location
|
Keep all the boxes together in a lockable cupboard.
|
|
Security
|
Ensure that only those authorised to install software
have access. Track comings and goings with an
in/out book and ensure that all staff record when
and what they have taken and when it has been
returned.
|
|
|
Build software can be defined as working copies of software, either stored on a file
server, on a boot disk/CD or as a computer disk image. If you keep build software
you must ensure that such use complies with your software licence agreements.
|
Storage
|
If you use a file-server for storage, create a common
area for all such copies with a logical folder
structure. See the example DSL folder structure in
the toolkit.
|
|
Location
|
For storage purposes, you can use any file server
that can be accessed from all points for installation
purposes. It is often the case that build software is
installed on a file server used only by ICT staff. This
is so that, if necessary, it can be taken offline
without impact on normal user activities.
|
|
Security
|
File-server areas should have access restricted to
those responsible for release software builds and
those authorised to install them. Full access should
be granted only to those responsible for release.
Installers should have read-only access rights.
It is important to put in place restrictions to
demonstrate that attempts have been made to
control access and preserve integrity. This is where
software tools designed specifically to manage
software releases demonstrate their benefits.
Disks or CDs should have the same security
applied as described in the section on original
software. |
|
|
Compliance with software licensing rules is very important. It can be difficult
sometimes to keep track of how many the school owns and how many are in use.
A simple way to do this is to create a spreadsheet or document with an entry for
each licence and then record the assignment of a licence each time it is installed.
We have created a licence list template for you to download and use. Keep a
separate list for each operating system or application and don't forget to add new
licences to the list when you buy them.
|
Storage
|
Store the physical licences somewhere safe and keep
them all together. For example, you could store them
in a locked cupboard with the original software. Keep the licence list in the definitive software library.
See the example DSL folder structure in toolkit for
ideas.
|
|
Location
|
The definitive software library and licence lists should
be on a file server that can be accessed by those
responsible for assigning licences and installing
software.
|
|
Security
|
The definitive software library and licence lists should
be accessible only by those authorised. It is important
to put in place restrictions to demonstrate that
attempts have been made to control access and
preserve integrity.
|
|
|
A service is the specific hardware or software type to be implemented, for example:
- a desktop computer
- a laptop computer
- a software application
- an operating system.
Each different service will have a separate release management procedure.
Select a suitable service with which to implement Release Management and your
first procedure. This should be a service that you are required to install currently
and you should follow the procedure through to installation. This will ensure that you
have tested all the steps before handing over the procedure to incident
management staff. You will gain the most benefit from starting with a frequently
requested service.
It may also help you to gain an approximate view of the overall number of services
currently in use. This in turn will help you to decide which ones to start with and will
give you a baseline from which to measure progress. See Monitoring the Release
Management process in the operations guide for more information on
measurements.
|
|
A 'build' is the service to be installed actually in working order. For example, the
build of a piece of software is its actual installation on the computer and its
interaction with the hardware and other software to deliver the service required. A
hardware build might be the connecting together of the base unit, monitor,
keyboard and mouse, the installation of the operating system and standard
software and the setting up of printer drivers to enable printing to a shared printer.
In other words, a 'build' is a working service as opposed to its component parts still
in boxes.
By going through the create build steps for a specific service, you will identify the
procedure to follow each time the service has to be installed.
To enable the process, we have created a build procedure template for you to use
as the starting point and add to with the specific details of each service. Save the
template as a separate document for each build and enter the name of the
document in the footer. We have also created an example build procedure for
hardware and an example build procedure for software to help you to understand
the requirements of the document and demonstrate how it can be used for either
type of service.
|
|
|
Section 1: Design
|
List the components of the service and include any relevant
comments.
|
|
Section 2: Build
|
Describe as fully as possible the steps required to install the
service.
|
|
Section 3: Test
|
List all other services that must remain stable in the same
environment and confirm successful test. Note that a build cannot
be released until all services are stable.
|
|
Section 4: Accept
|
Identify, in conjunction with an appropriate user or group of users,
suitable criteria for functionality acceptance. Describe the
acceptance tests as fully as possible.
|
|
|
A 'build' is the service to be installed actually in working order. For example, the
build of a piece of software is its actual installation on the computer and its
interaction with the hardware and other software to deliver the service required. A
hardware build might be the connecting together of the base unit, monitor,
keyboard and mouse, the installation of the operating system and standard
software and the setting up of printer drivers to enable printing to a shared printer.
In other words, a 'build' is a working service as opposed to its component parts still
in boxes.
The first step in the Release Management process is to create the build for the
particular service - see create build . When the build has been tested and
accepted, it can be released, that is, made available for installation using the build
procedure for that service - see release build steps .
|
|
|
Section 5: Store
software in DSL
|
In the definitive software library list the names and
versions of all software included in this build and note the
path to the location of the master copy. Physically store
the software in the location described and, when you've
done, tick in the box provided on the build procedure.
|
|
Section 6: Store
documents and
record in CMDB
|
Record the name and version of the build procedure. The
build procedure should be stored centrally - record the
path and save the document to that location under the
chosen file name. Don't forget to tick the box. Also store
all user documentation centrally and record the location.
If/when you have a configuration management database,
you should enter details there too.
|
|
Section 7:
Communicate
availability
|
List all the roles authorised to install hardware or software
and confirm that they have been informed of the new
build. See example build notification for a suggested
form of words. |
|
|
A 'build' is the service to be installed actually in working order. For example, the
build of a piece of software is its actual installation on the computer and its
interaction with the hardware and other software to deliver the service required. A
hardware build might be the connecting together of the base unit, monitor,
keyboard and mouse, the installation of the operating system and standard
software and the setting up of printer drivers to enable printing to a shared printer.
In other words a 'build' is a working service as opposed to its component parts still
in boxes.
|
|
|
Section 1: Install
details
|
Complete the checklist with the details specified.
Liaise with the user to schedule appropriate times for
installation and training.
|
|
Section 2: Install
checklist
|
Use the checklist to ensure that all steps are followed
and tick the boxes to confirm that this is the case.
|
|
Section 3: Install
document details
|
Save the install build checklist as a separate
document for each install and enter the name and
location of the file here.
|
|
|
|
|
|
