Release engineering

Last updated

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. [1] [2] that release engineering is to software engineering as manufacturing is to an industrial process:

Contents

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.

The importance of release engineering in enabling growth of a technology company has been repeatedly argued by John O'Duinn [3] and Bram Adams. [4] While it is not the goal of release engineering to encumber software development with a process overlay, it is often seen as a sign of organizational and developmental maturity.

Modern release engineering is concerned with several aspects of software production:

Identifiability
Being able to identify all of the source, tools, environment, and other components that make up a particular release.
Reproducibility
The ability to integrate source, third party components, data, and deployment externals of a software system in order to guarantee operational stability.
Consistency
The mission to provide a stable framework for development, deployment, audit and accountability for software components.
Agility
The ongoing research into what are the repercussions of modern software engineering practices on the productivity in the software cycle, e.g. continuous integration and push on green initiatives[ clarification needed ].

Release engineering is often the integration hub for more complex software development teams, sitting at the cross between development, product management, quality assurance and other engineering efforts, also known as DevOps. Release engineering teams are often cast in the role of gatekeepers (e.g. at Facebook, Google, Microsoft) for certain critical products where their judgement forms a parallel line of responsibility and authority in relation to production releases (pushes).

Frequently, tracking of changes in a configuration management system or revision control system is part of the domain of the release engineer. The responsibility for creating and applying a version numbering scheme into software—and tracking that number back to the specific source files to which it applies—often falls onto the release engineer. Producing or improving automation in software production is usually a goal of the release engineer. Gathering, tracking, and supplying all the tools that are required to develop and build a particular piece of software may be a release engineering task, in order to reliably reproduce or maintain software years after its initial release to customers.

While most software engineers, or software developers, do many or all of the above as a course of their work, in larger organizations the specialty of the release engineer can be applied to coordinate disparate source trees, projects, teams, and components. This frees the developers to implement features in the software and also frees the quality assurance engineers to more broadly and deeply test the produced software.

The release engineer may provide software, services, or both to software engineering and software quality assurance teams. The software provided may build tools, assembly, or other reorganization scripts which take compilation output and place them into a pre-defined tree structure, and even to the authoring and creation of installers for use by test teams or by the ultimate consumer of the software. The services provided may include software build (compilation) automation, automated test integration, results reporting, and production of or preparation for software delivery systems—e.g., in the form of electronic media (CDs, DVDs) or electronic software distribution mechanisms.

Related Research Articles

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

<span class="mw-page-title-main">Configuration management</span> Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a management process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

Software configuration management (SCM), a.k.a. software change and configuration management (SCCM), is the software engineering practice of tracking and controlling changes to a software system; part of the larger cross-disciplinary field of configuration management (CM). SCM includes version control and the establishment of baselines.

Software development is the process of designing and implementing a software solution to satisfy a user. The process is more encompassing than programming, writing code, in that it includes conceiving the goal, evaluating feasibility, analyzing requirements, design, testing and release. The process is part of software engineering which also includes organizational management, project management, configuration management and other aspects.

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 of building and testing frequently

Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state.

A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.

Build automation is the practice of building software systems in a relatively unattended fashion. The build is configured to run with minimized or no software developer interaction and without using a developer's personal computer. Build automation encompasses the act of configuring the build system as well the resulting system itself.

Quality engineering is the discipline of engineering concerned with the principles and practice of product and service quality assurance and control. In software development, it is the management, development, operation and maintenance of IT systems and enterprise architectures with high quality standard.

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.

<span class="mw-page-title-main">Release management</span> Process of software building

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.

<span class="mw-page-title-main">Definitive media library</span>

A definitive media library is a secure information technology repository in which an organisation's definitive, authorised versions of software media are stored and protected. Before an organisation releases any new or changed application software into its operational environment, any such software should be fully tested and quality assured. The definitive media library provides the storage area for software objects ready for deployment and should only contain master copies of controlled software media configuration items (CIs) that have passed appropriate quality assurance checks, typically including both procured and bespoke application and gold build source code and executables. In the context of the ITIL best practice framework, the term definitive media library supersedes the term definitive software library referred to prior to version ITIL v3.

DevOps is the integration and automation of the software development and information technology operations. DevOps encompasses necessary tasks of software development and can lead to shortening development time and improving the development life cycle. According to Neal Ford, DevOps, particularly through continuous delivery, employs the "Bring the pain forward" principle, tackling tough tasks early, fostering automation and swift issue detection. Software programmers and architects should use fitness function to keep their software in check.

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. 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.

<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.

Infrastructure as code (IaC) is the process of managing and provisioning computer data center resources through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The IT infrastructure managed by this process comprises both physical equipment, such as bare-metal servers, as well as virtual machines, and associated configuration resources. The definitions may be in a version control system, rather than maintaining the code through manual processes. The code in the definition files may use either scripts or declarative definitions, but IaC more often employs declarative approaches.

<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.

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

References

  1. ↑ Adams, Bellomo, Bird, Marshall-Keim, Khomh, Moir (March 2015). "The Practice and Future of Release Engineering". IEEE Software. 32 (2). IEEE Computer Society: 46. doi: 10.1109/ms.2015.52 .
  2. ↑ "Behind the Scenes - Production Pushes". 11 March 2009.
  3. ↑ John O'Duinn. 2015. Release engineering as a force multiplier. In Proceedings of the Third International Workshop on Release Engineering (RELENG '15). IEEE Press, Piscataway, NJ, USA, 1-1.
  4. ↑ 2013. Proceedings of the 1st International Workshop on Release Engineering. IEEE Press, Piscataway, NJ, USA.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.