FITS - Release Management

The first step is to identify the process participants and assign roles and responsibilities.  We recommend that for initial implementation you involve as few people as possible so that it can become familiar with minimum impact on the day-to-day workload of the school.

Who you select to fulfil the Release Management roles will depend on how you currently provide technical support and who is involved already. Assigning roles and responsibilities in Release Management  offers some suggestions and guidance.

After you have assigned roles and responsibilities, it is important to ensure that those participating in the implementation and subsequent operation of the process understand what is required of them.  Use this website as training material.

Set a start date.  A 'go-live' date is important in any implementation. Make sure that you allow enough time for all the other preparatory tasks to be carried out before 'go-live' date.

Communication must take place within the implementation team to agree plans, schedule dates, and so on, but it is also important to communicate externally and inform the user community of the new process and its benefits to them.

The implementation of a process can be seen as being a change just like the upgrading of a server and the impact on the user community should be communicated to them clearly in advance of the change. They will more readily embrace it if they are not taken by surprise.

Before you can go ahead with the implementation, you will need all the materials required for the process. Make sure that you have downloaded the templates you need and that everyone involved has access to them. 

Carry out a pilot implementation as a test first.  Practise creating a build procedure by installing a piece of software on a technical support computer.  Then use the procedure and standard installation checklist to install it again.  Follow all the instructions right down to storing the software in the definitive software library. 

It is important to test every aspect of the process in the pilot so that you can be sure that there are no outstanding issues.

FITS Release Management has been designed to be implemented on its own with no prerequisites.  However, the processes Release Management most closely interfaces with are Change Management and Configuration Management. Change Management's role in Release Management is in the approval and rollout of large releases to more than one end-user and, as such, is not recommended at this stage of implementing Release Management. Configuration Management is not essential at this stage either, but may be helpful in identifying the different services that need to be documented in Release Management.

There are no strict pre-requisites therefore and, if you wish, you can implement FITS Release Management in isolation.

Person with overall responsibility for Release Management or ICT in general, eg:

This may be delegated to someone in the ICT team but there should be only one release manager for the sake of accountability.

Person responsible for integrating new hardware or software into existing services, eg:

Build developers should be technical enough to install and test new hardware and software and also resolve any conflicts with existing services that may arise. 

Build developers and installers may be the same person.

Person responsible for confirming that the new hardware or software performs the functions it was obtained for, eg:

Acceptance testers should vary depending upon the service being tested.  Someone with intimate knowledge of the processes the hardware or software supports should perform this role.

The acceptance tester shouldn’t be the build developer or installer unless of course they are the end- user of the service or the service being tested is shared infrastructure.

Person responsible for performing day-to-day installations of hardware or software, eg:

An installer is likely to be the same person or people who carry out day-to-day technical support.  You may have as many or few installers as appropriate for your school.

Build developers and installers may be the same person.