Transcription

ReleaseManagementRelease Management ContentsRM 1 Topic introduction – Aim and objectives of this topic . . . . . . . . . . . . . . . . . . . . . . . . .1RM 2 Overview – An introduction to the process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1RM 3 Implementation guide – How to implement the process . . . . . . . . . . . . . . . . . . . . .5RM 4 Operations guide – The ongoing operation of the process . . . . . . . . . . . . . . . . . . .14RM 5 Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17RM 6 Review – Summary and checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31KeyGlossary term:Glossary termCross reference: Cross referenceFramework for ICT Technical Support

Release Management Becta 2004You may reproduce this material free of charge in any format or medium withoutspecific permission, provided you are not reproducing it for profit, material orfinancial gain. You must reproduce the material accurately and not use it in amisleading context. If you are republishing the material or issuing it to others, youmust acknowledge its source, copyright status and date of publication.Publication date March 2004Originally published online in September 2003 as part of the Becta websitehttp://www.becta.org.uk/tsasWhile every care has been taken in the compilation of this information to ensure thatit is accurate at the time of publication, Becta cannot be held responsible for any loss,damage or inconvenience caused as a result of any error or inaccuracy within thesepages. Although all references to external sources (including any sites linked to theBecta site) are checked both at the time of compilation and on a regular basis, Bectadoes not accept any responsibility for or otherwise endorse any product orinformation contained in these pages, including any sources.British Educational Communicationsand Technology Agency,Millburn Hill Road,Science Park,Coventry CV4 7JJ

Release ManagementRM 1 Introduction to Release ManagementDo you want to know how to roll out new software and hardware efficiently andeffectively? FITS Release Management tells you how.RM1.1AimThe aim of this section is to introduce Release Management and to help youimplement the process in your school with a minimum of preparation and training.RM1.2ObjectivesThe objectives of this section are to enable you to: understand the concept and benefits of Release Management understand what is involved in the process of Release Management understand the roles and responsibilities in Release Management implement a basic Release Management process in your school continue to operate this Release Management process identify useful measurements to gain benefit from the Release Managementprocess you have implemented review your implementation and summarise your progress.RM 2 OverviewRM2.1What is Release Management?What is Release Management?Release Management is the process of planning, building, testing and deployinghardware and software and the version control and storage of software.Its purpose is to ensure that a consistent method of deployment is followed. Itreduces the likelihood of incidents as a result of rollouts and ensures that onlytested and accepted versions of hardware and software are installed at any time.Why use Release Management?Release Management is proactive technical support focused on the planning andpreparation of new services. Some of the benefits are: Becta 2004 the opportunity to plan expenditure and resource requirements in advance a structured approach to rolling out all new software or hardware, which isefficient and effective changes to software are ‘bundled’ together for one release, which minimises theimpact of changes on users testing before rollout, which minimises incidents affecting users and requiresless reactive supportFITS Release Management1

an opportunity for users to accept functionality of software before it isfully implemented training in advance of rollout, which means that users do not experience systemdowntime while learning new features version control and central storage of software, ensuring that correct versions areinstalled at all times, which minimises incidents and the need for reinstallation.Who uses Release Management?Those responsible for ICT and ICT technical support use Release Management. Thesemay include external ocessRM2.2DefinitivesoftwarelibraryPlan anddevelopreleasePrepare forrollout ofreleasestep:initatestep:Define releasePolicystep:Release Managementprocess010203Execute rolloutof releaseHow Release Management worksThe Release Management process works by providing a consistent framework fordefining and creating new services, and ensuring that the correct versions of testedand approved software are implemented on a day-to-day basis (that is, afterinitial rollout).It interfaces with the Change Management process to enable implementation andto the Configuration Management process to maintain configuration records.The Release Management process flowchart (above) illustrates this.For further details see the sections below:RM2.2.1Release policyRelease policy is the strategy adopted for implementing new services. It can becomplex or simple.At a simple level, release policy may be the conscious decision to implement newcomputers only twice a year, for example, or to upgrade software in phases in acertain order such as by department. It is a high level plan that is agreed andpublished in advance to set expectation.At a complex level, release policy can relate to the actual development of softwareand determine frequency of new versions, version-numbering convention, types of Becta 2004FITS Release Management2

release such as full or partial, and so on. This applies more specifically to organisationswith their own software development function.RM2.2.2Definitive software libraryThe definitive software library (DSL) is a repository for storing released softwareand serves as the central point for obtaining versions of software for installation.Its purpose is to distinguish between old and new released versions and anydevelopment software.The definitive software library links to the configuration management database.RM2.2.3Release planningRelease planning is proactive technical support to ensure that software or hardwarebeing deployed to users does what it is required to do when they receive it. Releaseplanning includes design, build, test and acceptance.DesignBuildBuild is the compilation of components to form the service, such as the installationand set up of a new computer or the integration of a new piece of software withexisting applications on the desktop.TestTest is the internal technical support testing that should be carried out to ensurethat the service is stable and that other services have not been affected byits introduction.AcceptancetestingRMDesign relates to the architecture of a new ICT service. That is the configurationof the pieces of hardware and software involved.2.2.4Acceptance testing is functionality testing carried out by nominated users who areresponsible for ensuring that the service does what is required.Release rolloutRelease rollout is the actual deployment of the new hardware or software. Theterm ‘rollout’ implies the introduction of a new service to all or many computers orusers, but release management techniques can and should be applied to individualinstallations. Release rollout includes scheduling, training, communication, updatingthe definitive software library and checklists.SchedulingTrainingCommunication Becta 2004Scheduling is required for both the actual deployment of the service and anytraining that is required. Scheduling is particularly important for rollouts to morethan one computer or user, but even one installation should be scheduled inaccordance with the user’s preference.Training should always be considered prior to a rollout of new hardware or software.It may not always be necessary – for example if the rollout is of new computers toexisting computer users – but it is good practice to take the potential need fortraining into account.Communication is very important. Users need to be made aware that changes arebeing planned and how the schedule affects them.FITS Release Management3

Update definitivesoftware libraryChecklistsRM2.2.5Relationshipwith ChangeManagementRelationship withConfigurationManagementThe correct version of software to be installed must be available and marked clearlyin the definitive software library in time for rollout.The actual deployment should also be structured to ensure that all activities arecompleted and the rollout is consistent. Checklists should be available for theinstallers to follow.Relationships with other processesThe Release Management process interfaces with the Change Managementprocess throughout its lifecycle. Release management provides the inputs to therequest for change at the various stages of planning and preparation. Changemanagement final approval should be received before the new service is deployedinto the live environment.The Release Management process links closely to Configuration Management. Thefinal step in the release of a new service or an upgrade to an existing service is torecord the changes in the configuration management database. This is facilitated bythe Change Management process or the incident/request process as appropriate.The definitive software library is also considered to be part of the configurationmanagement database.RM2.3What does Release Management cost?Release Management can cost as little or as much as you can afford. There are threeaspects to consider: expenditure, people and time.You incur financial expenditure only if software tools are purchased for the definitivesoftware library and additional hardware is required to accommodate it. Specificproducts are available to manage security and version control, but these are onlyreally needed in a software development environment or regulated industry suchas pharmaceuticals.Release Management requires full time staff only if there is a large volume of newservices and upgrades requiring full-time effort for planning and execution. Thissometimes applies in large organisations. In a school, Release Management activitiesshould be part time and you should be able to allocate the roles and responsibilitiesto existing members of staff. Roles and responsibilities are referred to throughoutthe Release Management section, and are grouped together in RM 5 Roles andresponsibilities.The amount of time taken up by the Release Management process once it isoperational is difficult to quantify, as this will depend on the frequency of releaseof new services in your school. It is worth investing time in the planning stages ofintroducing new services and implementing them in a consistent way to avoid thedisruption and downtime that may occur later if they are badly executed. It is alwaysbetter to spend time on prevention rather than cure.Remember to allow time also for the implementation and integration of the processinto normal day-to-day activities. We have created a table of activities to help youplan the amount of time required. Becta 2004FITS Release Management4

RMTable of activities2.3.1ActivityPreparing forimplementationExampleFurther informationDiscussions, planningRM 3 Implementation guideTraining, pilot, actual implementationRM 3 Implementation guideDifficulties with process or rolesRM 3 Implementation guideDesigning, building, testing andacceptance testing of releases ofhardware or softwareRM 4 Operations guideScheduling and executing training,scheduling deployment, communicatingwith users, preparing checklists forinstallers, deployment of releases.RM 4 Operations guideReporting against the process andensuring that it is effectiveRM 4 Operations guideImplementationReview ofimplementationPreparing releasesCarrying outinstallationsMonitoringthe processRM 3 Implementation guideRMDefine what needs to be done3.1As described in the overall FITS implementation approach, we recommend a phasedapproach to implementing new processes.The FITS ethic is ‘keep it simple’. FITS also promotesa cyclic approach to its implementation: start smalland make continuous improvements.processtoolsFITS implementationfor continuous improvement.informationThis first set of material introduces the processeswith easy to follow instructions and simple tools touse. When you have implemented the processes,you will use the tools to gather information to makefurther improvements and thus enter the next cycle.This process of refinement allows you to implementbest practice in manageable, bite-size pieces. Youwill therefore reap the benefits from an early stageand not be overwhelmed by extra work.Structured implementation of best practice processesfor continuous improvement. Becta 2004FITS Release Management5

FITS Release Management is for people with little free time to spend onimplementing processes and procedures and whose day-to-day activities areunpredictable and must take priority.Our aim is to help you begin to remove some of the unpredictability by introducingbest practice processes in small steps and so begin to realise the benefits as quicklyas possible.ProcessImplement Release Management process for individualreleases only and test process in a small groupprocesstoolsRelease Managementinformation Identify builds and create procedure to testand install for each Use procedures to install each time Implement central store of software Create build procedures for all new services asthey are introducedToolsKeep tools simple and requiring minimum effort Use document templates for proceduresand checklists Use Excel template for reportRelease Management implementation approachInformationStart to gather data immediately to demonstrateprogress and produce monthly or weeklyreport including number of builds installed in period number of builds created in period total number of builds documented total number of services in school number of services remaining to documentLong-term scopeIn the long-term, Release Management should be applied as a strategy forintroducing all new software or hardware in a planned, controlled and structuredmanner. This should therefore reduce the need for ad hoc requirements as far aspossible and allow technical support time to be focused on other activities. It alsoresults in economies of scale as the planning and preparation activities do notincrease in proportion to the number of items – these tasks must be performedwhether the exercise is to install one computer or 10.However, to ensure the best chance of success, application of Release Managementto this extent is best left until the basic concepts are fully understood and automatic.Short-term scopeIn the short-term, Release Management should be applied to the installation of singleinstances of hardware or software. This exercise can be used to begin the generationof standard builds and a centralised store of software and introduces the concept ofa standard process for implementing all equipment. In addition, by constraining theRelease Management process to single installations, you can avoid the need to interfaceto the Change Management process. This means that Release Management can beimplemented in isolation with no prerequisite for a Change Management process.Once the basic activities are comfortably in place, it will be a relatively easy step toconsider the bigger picture and to plan and manage larger rollouts that will requireinput to the Change Management process. Becta 2004FITS Release Management6

RM3.2Prepare to implementGood preparation can make the difference between a successful implementationof a process and an unsuccessful one.Roles andresponsibilitiesThe 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 possibleso that it can become familiar with minimum impact on the day-to-day workloadof the school.Who you select to fulfil the Release Management roles will depend on how youcurrently provide technical support and who is involved already. RM 3.2.1 Assigningroles and responsibilities in Release Management offers some suggestions and guidance.TrainingAfter you have assigned roles and responsibilities, it is important to ensure thatthose participating in the implementation and subsequent operation of the processunderstand what is required of them. Use the FITS website as training material.Start dateSet a start date. A ‘go-live’ date is important in any implementation. Make sure thatyou allow enough time for all the other preparatory tasks to be carried out beforeyour ‘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 externallyand inform the user community of the new process and its benefits to them.CommunicationMaterialsPilotThe implementation of a process can be seen as being a change just like theupgrading of a server and the impact on the user community should becommunicated to them clearly in advance of the change. They will morereadily embrace it if they are not taken by surprise.Before you can go ahead with the implementation, you will need all the materialsrequired for the process. Make sure that you have downloaded the templates youneed and that everyone involved has access to them.Carry out a pilot implementation as a test first. Practise creating a build procedureby installing a piece of software on a technical support computer. Then use theprocedure and standard installation checklist to install it again. Follow all theinstructions 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 besure that there are no outstanding issues.PrerequisitesFITS Release Management has been designed to be implemented on its ownwith no prerequisites. However, the processes Release Management most closelyinterfaces with are Change Management and Configuration Management. ChangeManagement's role in Release Management is in the approval and rollout of largereleases to more than one end-user and, as such, is not recommended at this stageof implementing Release Management. Configuration Management is not essentialat this stage either, but may be helpful in identifying the different services thatneed to be documented in Release Management.There are no strict prerequisites therefore and, if you wish, you can implementFITS Release Management in isolation. Becta 2004FITS Release Management7

RM3.2.1RoleRelease managerAssigning roles and responsibilities in Release ManagementSuggested representative(s)CommentsPerson with overall responsibilityfor Release Management or ICT ingeneral, eg:This may be delegated to someone inthe ICT team but there should be onlyone release manager for the sakeof accountability. ICT manager ICT co-ordinator network manager technician.Person responsible for integratingnew hardware or software intoexisting services, eg:Build developer technician ICT co-ordinator network manager supplier.Person responsible for confirmingthat the new hardware or softwareperforms the functions it wasobtained for, eg:Acceptancetester teacher teaching assistant administrative staff any end-user.Person responsible for performingday-to-day installations of hardwareor software, eg:InstallerRM3.3 technician ICT co-ordinator network manager supplier.Build developers should be technicalenough to install and test new hardwareand software and also resolve any conflictswith existing services that may arise.Build developers and installers may bethe same person.Acceptance testers should varydepending upon the service being tested.Someone with intimate knowledge ofthe processes the hardware or softwaresupports should perform this role.The acceptance tester shouldn’t be thebuild developer or installer unless ofcourse they are the end-user of theservice or the service being tested isshared infrastructure.An installer is likely to be the sameperson or people who carry out day-today technical support. You may have asmany or as few installers as appropriatefor your school.Build developers and installers may bethe same person.ImplementThis section describes how to implement a basic release management process andthe tools required to support it. Becta 2004 Step 1: Define policy Step 2: Create definitive software library Step 3: Identify service Step 4: Create build Step 5: Release build Step 6: Install buildFITS Release Management8

createDefine releasepolicystep:Releasepolicystep:Create DSLIdentify servicestep:ICT strategynew e in03Build procedurecreateNameDesignstep:Create buildstep:Release buildstep:Release build04createBuildTestAcceptStore software0506Store documentscreateCommunicateInstall build checklistPrepareInstallFITS Release management processStep 1 Define policyThe release policy is something that should be determined locally. However, inorder to implement Release Management effectively, we recommend the followinginitial policy. Create and follow a standard process for installing and testing new userhardware and software. Create and follow a standard procedure for each different hardware andsoftware service. Store all software centrally.Step 2 Create definitive software libraryIn basic terms, a definitive software library is the central storage and control oforiginal software, build software and software licences – for more details of whichsee overleaf.You should make it a policy to create and develop a definitive software library to helpyou manage your software licence allocation and ensure that the correct versions ofsoftware are installed. It also saves time searching for original disks when you are ina hurry to install something. It is about tidiness as much as anything else. Becta 2004FITS Release Management9

Original softwareAlways retain original software – at least one set of each version – in a central library.StorageDiskette or CD boxes provide adequate storage for original softwareLocationKeep all the boxes together in a lockable cupboard.SecurityEnsure that only those authorised to install software have access. Track comingsand goings with an in/out book and ensure that all staff record when and whatthey have taken and when it has been returned.Build softwareBuild software can be defined as working copies of software, either stored on a fileserver, 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.StorageIf you use a file-server for storage, create a common area for all such copies with alogical folder structure. See Appendix A for our example DSL folder structure.Disks or CDs should be kept as described in the section below on original software.LocationFor storage purposes, you can use any file server that can be accessed from all pointsfor installation purposes. It is often the case that build software is installed on a fileserver used only by ICT staff. This is so that, if necessary, it can be taken offlinewithout impact on normal user activities.Disks or CDs should be kept as described in the section above on original software.File-server areas should have access restricted to those responsible for releasesoftware builds and those authorised to install them. Full access should be grantedonly to those responsible for release. Installers should have read-only access rights.SecurityIt is important to put in place restrictions to demonstrate that attempts have beenmade to control access and preserve integrity. This is where software tools designedspecifically to manage software releases demonstrate their benefits.Disks or CDs should have the same security applied as described in the sectionabove on original software.Software licencesCompliance with software licensing rules is very important. It can be difficultsometimes 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 eachlicence and then record the assignment of a licence each time it is installed. We havecreated a licence list template (see Appendix B) for you to download and use. Keep aseparate list for each operating system or application and don’t forget to add newlicences to the list when you buy them. Becta 2004FITS Release Management10

StorageLocationSecurityStore the physical licences somewhere safe and keep them all together. For example,you could store them in a locked cupboard with the original software (see above).Keep the licence list in the definitive software library. See our example DSL folderstructure (Appendix A) for ideas.The definitive software library and licence lists should be on a file server that can beaccessed by those responsible for assigning licences and installing software.The definitive software library and licence lists should be accessible only by thoseauthorised. It is important to put in place restrictions to demonstrate that attemptshave been made to control access and preserve integrity.Step 3 Identify serviceA 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 yourfirst procedure. This should be a service that you are required to install currently andyou should follow the procedure through to installation. This will ensure that youhave tested all the steps before handing over the procedure to incident managementstaff. 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 servicescurrently in use. This in turn will help you to decide which ones to start with and willgive you a baseline from which to measure progress. See RM 4.2.3 Monitoring theRelease Management process for more information on measurements.Step 4 Create buildA ‘build’ is the service to be installed actually in working order. For example, the buildof a piece of software is its actual installation on the computer and its interactionwith the hardware and other software to deliver the service required. A hardwarebuild might be the connecting together of the base unit, monitor, keyboard andmouse, the installation of the operating system and standard software and thesetting 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 (see overleaf ) for a specific service, you willidentify the procedure to follow each time the service has to be installed.To enable the process, we have created a build procedure template (see Appendix Cfor hardware or Appendix D for software) for you to use as the starting point and addto with the specific details of each service. Save the template as a separate documentfor each build and enter the name of the document in the footer. We have also createdan example build procedure for hardware (see Appendix C) and an example buildprocedure for software (see Appendix D) to help you to understand the requirementsof the document and demonstrate how it can be used for either type of service. Becta 2004FITS Release Management11

Create build stepsUsing the build procedure template (see Appendix C for hardware or Appendix Dfor software), complete the sections as described below. See also the example buildprocedure for hardware (see Appendix C) and example build procedure for software(see Appendix D).Section 1: DesignSection 2: BuildSection 3: TestSection 4: AcceptList the components of the service and include any relevant comments.Describe as fully as possible the steps required to install the service.List all other services that must remain stable in the same environment and confirmsuccessful test. Note that a build cannot be released until all services are stable.Identify, in conjunction with an appropriate user or group of users, suitable criteriafor functionality acceptance. Describe the acceptance tests as fully as possible.Step 5 Release buildA ‘build’ is the service to be installed actually in working order. For example, the buildof a piece of software is its actual installation on the computer and its interactionwith the hardware and other software to deliver the service required. A hardwarebuild might be the connecting together of the base unit, monitor, keyboard andmouse, the installation of the operating system and standard software and thesetting 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 theparticular service – see Step 4. When the build has been tested and accepted, itcan be released – that is, made available for installation using the build procedurefor that service (see section below on release build steps).Release build stepsUsing the build procedure template (see Appendix C for hardware or Appendix Dfor software), follow the instructions for the sections as described below. See alsoexample

Release Management is the process of planning, building, testing and deploying hardware and software and the version control and storage of software. Its purpose is to ensure that a consistent method of deployment is followed. It reduces the likelihood of incidents as a result of rollouts and ensures that onlyFile Size: 316KBPage Count: 38Explore furtherRelease Management Checklist and Steps - Software Project .www.htae.net5 Steps to a Successful Release Management Process .www.lucidchart.comITIL Release Planning Template Process Streetwww.process.stSoftware Deployment Checklists / Rollout Planswww.it-checklists.com25 Release Management KPI You Should Be Trackingblog.inedo.comRecommended to you b