11-12-2012 Vol. 10 MAVERIC S POINT OF VIEW Abstract: This paper highlights the guidelines that should be taken into consideration, including the tools and the processes, that are to be in place for efficient and effective Release Management in any organization. Recommendations for Successful Release Management www.maveric-systems.com
Introduction Profitability and competitiveness of modern businesses are dependent on a steady flow of new applications, as well as changes and enhancements to existing applications. Slow, inconsistent and unreliable application release management often cause configuration errors, resulting in expensive application downtime or noncompliance with corporate, legal or regulatory standards. More and more organizations are finding that they do not need to live with the status quo of failed deployments, ballooning support costs and unexplained outages. Instead, they are using robust application release management processes and tools to reduce the pain, delay and costs now associated with application deployment. This white paper describes the recommended best practices for streamlining Release Management. Glossary The following table lists a set of terms used in Release Management. Term Release Release package Release type Release policy Release calendar Baseline Build Deployment unit Definition A stable, executable version of a product intended for deployment to testing and production A logical container that defines the set of RFCs and deployment units (sometimes called release units) that are to be included in a release. It also includes metadata such as the type of release (see release type) and its planned dates (see release calendar) The type of release that is to be implemented, i.e., major, minor, emergency. Each release type will usually have a different workflow An organization s published policy that determines under which circumstances different release types should be used as well as the standard set of milestones that selecting a particular release type implies in the release calendar A set of published milestones that details when releases are planned to transition through the different development, test and production phases A snapshot of the exact versions of configuration items, including executables, libraries, configuration files and documentation that are to be deployed An operational version of a product or part of a product. Not all builds are released but builds are typically carried to transform inputs (source code) into executed and installable deployment units A physical, self-contained, installable release of an application The practices Release Management is all about controlling the release process, coordinating information about all your releases, securing the path to production and automating your release process and deployments. The following good practices are based on many years of implementing and observing software Release Management across enterprises. They are listed in no particular priority or order. 2
1. Targeted release dates to be defined on a regular basis It is very vital and important to religiously plan, manage and deliver your releases regularly. The first step is to create a calendar on releases for each type product s release package to ensure that release progress is effectively communicated and planned. In case a number of releases are being developed in parallel, it is important to create and communicate a high-level release milestone plan. The calendar should communicate development, testing and deployment / live milestones. Use of a database or workflow tool will help to easily manage and communicate release packages and release calendar. 2. Release policy and process framework should be documented Policies and processes pertaining to software Release Management should be clearly defined and documented. The Release Management process framework must specify Types of release you will manage, their workflows and the default calendars Individuals responsible for planning, scheduling and managing each part of the release process Individuals responsible for building / packaging and delivering / deploying the release internally and externally Artifacts that are created as part of the release process. This could include release plan, release notes and installation instructions along with who is responsible for generating them The expectations of the business owners during the planning and rollout of new releases should be explicitly brought out in release policies and processes. 3. Have an independent release function Developers should not be allowed to transition deployment units into a live environment as there is a potential conflict of interest when known errors and workarounds arise during the releases. For auditability and traceability, it is better to have a separate release function to coordinate final physical delivery of the service, release documentation and communications. Release function is responsible for planning the releases based on directions from the Change Authorization Board / Release Authorization Board and publishing the release calendar. The release function is responsible for creating the logical release package s and communicating release dates. This function manages the build process and packages up the results of the build into the deployment unit. They usually deploy (in test, production and DR environments) or pass the deployment unit to a separate deployment team. 4. Deployment units should be constructed early As applications are moved from development to various levels of testing (System, SIT, UAT), you should be constructing deployment units with the potential to be installed, for example, a J2EE.EAR file together with related artifacts. This will prove the build, packaging and installation process early and at each phase. 3
5. Deployment process to be tested before actual deployment It is mandatory to test the deployment process flow at least once before any release is put into a live environment to check that your activities execute as expected and that the correct release is passed. The tests must verify the process flow and ability of the staff to complete the tasks assigned to them as part of the deployment process. This is normally carried out on acceptance test / pre-production environment that mimics the live environment and is controlled in the same way. 6. Have rollback or back-out plan A back-out plan includes detailed steps and techniques for uninstalling a new system, as well as reversing process changes. You should always have a tested back-out plan for releases that are being deployed to production environments. For example, if you deploy a new release onto the live servers and subsequently find that there are problems with it, you should have a plan that specifies the processes (automatic as possible) for restoring the system to its earlier state by removing this release and rolling back to the previous one. 7. Release Management automation tools The number of applications and releases has been increasing steadily over the last decade and this has led to an increase in both the complexity of releases and the cost of failure for releases. Manual release processes are repetitive and error prone; therefore it should be automated to create an efficient and controlled release process. At the very least, the inputs and outputs of the release process (including the build components and release documentation) should be versioned using a configuration management tool. 8. Configuration and Release Management tool Deploying multiple releases in parallel is critical for software companies as the challenge is to provide fixes and to understand what changes have gone into each release. It is also important to keep changes in sync between multiple projects going forward for rebasing or delivering changes between the projects, depending on the direction or sequence you want the changes to flow. Hence use of an integrated change configuration and Release Management software suite is necessary as it significantly helps to automate and reduce errors in the otherwise manual branching and merging process. 9. Identify and document all items linked to deployment unit Identify each product that is built and released: the hardware required, necessary supporting third-party software and the installation and configuration instructions. The release package can either relate all this together in documentation form or, better still, reference entries in a database called the CMDB (Configuration Management Database) in ITIL. 4
Conclusion Release Management surveys by several leading firms confirm that business is frustrated with the slow, inconsistent and unreliable Release Management process. Large enterprises have hundreds of application development projects and enhancements every year requiring frequent releases. This is motivating organizations to streamline their Release Management processes. They are achieving this by improving prebuild processes, implementing predefined release calendars, defining and implementing robust policies & procedures, and deploying integrated Release Management tools. Adopting any one of these practices is sure to bring improvement, so go ahead and pick one, start with an easier practice, carefully measure the results, feel the change and then adopt more practices in future. References 1. Release Management Best Practice Handbook: Building, Running and Managing by Gerard Blokdijk, Ivanka Menken, Emereo Pty Ltd. 2. www.buildmeister.com/articles/software_release_management_best_practices. Article - Software Release Management Best Practices Posted by buildmeister on 27/10/07. Author Reena Magdalene S, Consultant - Process Assurance 5
MAVERIC SYSTEMS 2012 We re a leading provider of assurance services across the technology adoption lifecycle bringing tangible value to clients by singularly focusing on enhancing quality from requirements to release. Our Program Assurance, Process Assurance and Application Assurance services bring end-to-end assurance capabilities to client engagements. We take accountability for requirements definition, requirements validation, comprehensive functional & non-functional testing and quality process assessment, definition & improvement. We support clients through managed testing services as well as testing of packaged applications. We have supported a large number of clients (in banking, insurance and telecom verticals) over the last decade through their transformation programs involving implementation of core business systems, CRM systems, payment systems, billing systems and other sub-systems. We power technology-led business transformation programs for leading corporates through our definitive domain expertise, superior knowledge of industry-standard solutions, innovative testing productivity accelerators and relentless passion. Headquartered in Chennai, we have offices in Mumbai, Bangalore, Dubai, Riyadh, London, New Jersey, Kuala Lumpur and Singapore. We also have a dedicated global offshore delivery center and a Testing R&D lab in Chennai. Maveric Systems Limited (Corporate Office): Fagun Mansion, 74, Ethiraj Salai, Egmore, Chennai - 600 105. Phone: +91-44 - 2820 7690. Fax: +91-44 - 2820 7691. Write to us at info@maveric-systems.com www.maveric-systems.com The contents of this document are entirely a Maveric perspective and is based on our experience and expertise in the industry. All rights reserved.