Release management

Last updated
Common names of versions during different stages in software development Alfa-Beta-Gamma.png
Common names of versions during different stages in software development

Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; it includes testing and deploying software releases. [1] [2]

Contents

Relationship with processes

Organizations that have adopted agile software development are seeing much higher quantities of releases[ citation needed ]. With the increasing popularity of agile development a new approach to software releases known as continuous delivery is starting to influence how software transitions from development to a release. [3] One goal of continuous delivery and DevOps is to release more reliable applications faster and more frequently. The movement of the application from a "build" through different environments to production as a "release" is part of the continuous delivery pipeline. [4] Release managers are beginning to utilize tools such as application release automation and continuous integration tools to help advance the process of continuous delivery and incorporate a culture of DevOps by automating a task so that it can be done more quickly, reliably, and is repeatable. More software releases have led to increased reliance on release management and automation tools to execute these complex application release processes. [5]

Relationship with ITIL/ITSM

In organizations that manage IT operations using the IT service management paradigm, specifically the ITIL framework, release management will be guided by ITIL concepts and principles. There are several formal ITIL processes that are related to release management, primarily the release and deployment management process, which "aims to plan, schedule and control the movement of releases to test and live environments", [6] and the change management process [7] In ITIL organizations, releases tend to be less frequent than in an agile development environment. Release processes are managed by IT operations teams using IT service management ticketing systems, with less focus on automation of release processes. [8]

Related Research Articles

Information technology service management (ITSM) are the activities performed by an organization to design, build, deliver, operate and control information technology (IT) services offered to customers.

Software deployment is all of the activities that make a software system available for use.

<span class="mw-page-title-main">Continuous integration</span> Software development practice based on frequent submission of granular changes

In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day. Nowadays it is typically implemented in such a way that it triggers an automated build with testing. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.

Release engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. that release engineering is to software engineering as manufacturing is to an industrial process:

Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results, and scales well. These industrial style practices not only contribute to the growth of a company but also are key factors in enabling growth.

Build automation is the process of automating the creation of a software build and the associated processes including: compiling computer source code into binary code, packaging binary code, and running automated tests.

Azure DevOps Server is a Microsoft product that provides version control, reporting, requirements management, project management, automated builds, testing and release management capabilities. It covers the entire application lifecycle and enables DevOps capabilities. Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.

A change-advisory board (CAB) delivers support to a change-management team by advising on requested changes, assisting in the assessment and prioritization of changes. This body is generally made up of IT and Business representatives that include: a change manager, user managers and groups, product owners, technical experts, and possible third parties and customers.

AnthillPro is a software tool originally developed and released as one of the first continuous integration servers. AnthillPro automates the process of building code into software projects and testing it to verify that project quality has been maintained. Software developers are able to identify bugs and errors earlier by using AnthillPro to track, collate, and test changes in real time to a collectively maintained body of computer code.

DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, following a pipeline through a "production-like environment", without doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Application-release automation (ARA) refers to the process of packaging and deploying an application or update of an application from development, across various environments, and ultimately to production. ARA solutions must combine the capabilities of deployment automation, environment management and modeling, and release coordination.

<span class="mw-page-title-main">BuildMaster</span>

BuildMaster is an application release automation tool, designed by the software development team Inedo. It combines build management and ARA capabilities to manage and automate processes primarily related to continuous integration, database change scripts, and production deployments, overall releasing applications reliably. The tool is browser-based and able to be used "out-of-the-box". Its feature set and scope puts it in line with the DevOps movement, and is marketed as "more than a release automatigs together the people, processes, and practices that allow teams to deliver software rapidly, reliably, and responsibly.” It's a tool that embodies incremental DevOps adoption.

In software deployment, an environment or tier is a computer system or set of systems in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use, the development environment and production environment are separated, often with several stages in between. This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.

<span class="mw-page-title-main">DevOps toolchain</span> DevOps toolchain release package.

A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organisation that uses DevOps practices.

Continuous configuration automation (CCA) is the methodology or process of automating the deployment and configuration of settings and software for both physical and virtual data center equipment.

DataOps is a set of practices, processes and technologies that combines an integrated and process-oriented perspective on data with automation and methods from agile software engineering to improve quality, speed, and collaboration and promote a culture of continuous improvement in the area of data analytics. While DataOps began as a set of best practices, it has now matured to become a new and independent approach to data analytics. DataOps applies to the entire data lifecycle from data preparation to reporting, and recognizes the interconnected nature of the data analytics team and information technology operations.

In software engineering, blue–greendeployment is a method of installing changes to a web, app, or database server by swapping alternating production and staging servers.

<i>Accelerate</i> (book)

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations is a software engineering book co-authored by Nicole Forsgren, Jez Humble and Gene Kim. The book explores how software development teams using Lean Software and DevOps can measure their performance and the performance of software engineering teams impacts the overall performance of an organization.

TestOps refers to the discipline of managing the operational aspects of testing within the software delivery lifecycle.

References

  1. Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. p. 110. ISBN   978-0-321-60191-9.
  2. Bays, Michael E. (1999). Software release methodology. Upper Saddle River, N.J.: Prentice Hall PTR. ISBN   0-13-636564-7. OCLC   41411901.
  3. Ambler, Scott W. (12 February 2014). "We need more Agile IT Now!". Dr. Dobb's the World of Software Development. San Francisco: UBM.
  4. Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. pp. 255–257. ISBN   978-0-321-60191-9.
  5. Best Practices in Change, Configuration and Release Management (Report). Gartner. 14 July 2010.
  6. "ITIL Release and Deployment Management". IT Process Maps. Germany: Stefan and Andrea Kempter. 15 May 2016.
  7. Murphy, Vawns (2 Feb 2016). "Change vs Release Management". The ITSM Review. UK: Enterprise Opinions Limited.
  8. "ITIL/ITSM Release Management Practices". Release Management Wiki. USA: Electric Cloud.