Software Release Life
Cycle
A software release life cycle is the sum of the stages of development and
maturity for a piece of computer software:
ranging from its initial development to its eventual release, and including
updated versions of the released version to help improve software or fix bugs still present in the software.
Stages of Development
History
The origin of the
"alpha/beta" test terminology is IBM. As long ago as the 1950s (and
probably earlier), IBM used similar terminology for their hardware development.
"A" test was the verification of a new product before public
announcement. "B" test was the verification before releasing the
product to be manufactured. "C" test was the final test before
general availability of the product. As software became a significant part of IBM's
offerings, the alpha test terminology was used to denote the pre-announcement
test and beta test was used to show product readiness for general availability.
Martin Belsky, a manager on some of IBM's earlier software projects claimed to
have invented the terminology. IBM dropped the alpha/beta terminology during
the 1960s, but by then it had gotten fairly wide notice. The usage of
"beta test" to refer to testing done by customers was not done in
IBM. Rather, IBM used the term "field test."
Pre-alpha
Pre-alpha refers to all
activities performed during the software project before testing. These
activities can include requirements analysis, software design, software
development, and unit testing. In typical open source development, there are
several types of pre-alpha versions. Milestone versions include specific sets
of functions and are released as soon as the functionality is complete.
Alpha
The alpha phase of the release
life cycle is the first phase to begin software testing (alpha is the first
letter of the Greek alphabet, used as the number 1). In this phase, developers
generally test the software using white box techniques. Additional validation
is then performed using black box or gray box techniques, by another testing
team. Moving to black box testing inside the organization is known as alpha
release.
Alpha software can be unstable
and could cause crashes or data loss. External availability of alpha software
is uncommon in proprietary software. However, open source software, in
particular, often have publicly available alpha versions, often distributed as
the raw source code of the software. The alpha phase usually ends with a
feature freeze, indicating that no more features will be added to the software.
At this time, the software is said to be feature complete.
Beta
Beta, named after the second
letter of the Greek alphabet, is the software development phase following
alpha. It generally begins when the software is feature complete. Software in
the beta phase will generally have many more bugs in it than completed software,
as well as speed/performance issues and may still cause crashes or data loss.
The focus of beta testing is reducing impacts to users, often incorporating
usability testing. The process of delivering a beta version to the users is
called beta release and this is typically the first time that the software is
available outside of the organization that developed it.
The users of a beta version are
called beta testers. They are usually customers or prospective customers of the
organization that develops the software, willing to test the software without
charge, often receiving the final software free of charge or for a reduced
price. Beta version software is often useful for demonstrations and previews
within an organization and to prospective customers. Some developers refer to
this stage as a preview, prototype, technical preview (TP), or early access.
Some software is kept in perpetual beta—where new features and functionality
are continually added to the software without establishing a firm "final"
release.
Open and Closed Beta
Developers release either a
closed beta or an open beta; closed beta versions are released to a restricted
group of individuals for a user test by invitation, while open beta testers are
from a larger group, or anyone interested. The testers report any bugs that
they find, and sometimes suggest additional features they think should be
available in the final version. Examples of a major public beta test are:
- In September 2000 a boxed version of Apple's Mac OS X Public Beta operating system was released.
- Microsoft's release of community technology previews (CTPs) for Windows Vista in January 2005.
Open betas serve the dual
purpose of demonstrating a product to potential consumers, and testing among an
extremely wide user base likely to bring to light obscure errors that a much
smaller testing team might not find.
Impact
of the World Wide Web
As the Internet has facilitated
rapid and inexpensive distribution of software, companies have begun to take a
looser approach to use of the word "beta".[5] In February 2005 ZDNet
published an article about the recent phenomenon of a beta version often
staying for years and being used as if it were in production level,
disparagingly called "perpetual beta". It noted that Gmail and Google
News, for example, had been in beta for a long period of time and were not
expected to drop the beta status despite the fact that they were widely used;
however, Google News did leave beta in January 2006, followed by Google Apps,
including Gmail, in July 2009.[6] This technique may allow a developer to delay
offering full support and responsibility for remaining issues. In the context
of Web 2.0, people even talk of perpetual betas to signify that some software
is meant to stay in beta state. Also, "beta" is sometimes used to
indicate something more like a release candidate, or as a form of time-limited
demo, or marketing technique .
Release Candidate
A release candidate (RC) is a
beta version with potential to be a final product, which is ready to release
unless significant bugs emerge. In this stage of product stabilization, all
product features have been designed, coded and tested through one or more beta
cycles with no known showstopper-class bug. A release is called code complete
when the development team agrees that no entirely new source code will be added
to this release. There could still be source code changes to fix defects,
changes to documentation and data files, and peripheral code for test cases or
utilities. Beta testers, if privately selected, will often be credited for
using the release candidate as though it were a finished product. Beta testing
is conducted in a client's or customer's location and to test the software from
a user's perspective.
Release
Release to Manufacturing (RTM)
The term "release to
manufacturing", also known as "going gold", is a term used when
a software product is ready to be delivered or provided to the customer. This
build may be digitally signed, allowing the end user to verify the integrity
and authenticity of the software purchase. A copy of the RTM build known as the
"gold master" or GM is sent for mass duplication. RTM precedes
general availability (GA), when the product is released to the public.
It is typically used in certain
retail mass-production software contexts—as opposed to a specialized software
production or project in a commercial or government production and
distribution—where the software is sold as part of a bundle in a related
computer hardware sale and typically where the software and related hardware is
ultimately to be available and sold on mass/public basis at retail stores to
indicate that the software has met a defined quality level and is ready for
mass retail distribution. RTM could also mean in other contexts that the
software has been delivered or released to a client or customer for
installation or distribution to the related hardware end user computers or
machines. The term does not define the delivery mechanism or volume; it only
states that the quality is sufficient for mass distribution. The deliverable
from the engineering organization is frequently in the form of a golden master
media used for duplication or to produce the image for the web.
General availability (GA)
General availability (GA) is
the marketing stage at which all necessary commercialization activities have
been completed and a software product is available for purchase, depending,
however, on language, region, electronic vs. media availability.[8]
Commercialization activities could include security and compliance tests, as
well as localization and world wide availability. The time between RTM and GA
can be from a week to months in some cases before a generally available release
can be declared because of the time needed to complete all commercialization
activities required by GA. At this stage, the software has "gone
live".
Release to Web
Release to web or web release
is a means of software delivery that utilizes the Internet for distribution. No
physical media are produced in this type of release mechanism by the
manufacturer. Web releases are becoming more common as Internet usage grows.
Support
During its supported lifetime,
software is sometimes subjected to service releases, or service packs,
sometimes also called "interim releases". For example, Microsoft
released three major service packs for the 32-bit editions of Windows XP and two
service packs for the 64-bit editions. Such service releases contain a
collection of updates, fixes and enhancements, delivered in the form of a
single installable package. They may also implement new features. Some software
is released with the expectation of regular support. Classes of software that
generally involve protracted support as the norm include anti-virus suites and
massively multiplayer online games. A good example of a game that utilizes this
process is Minecraft, an Indie Game developed by Mojang, which features regular
"updates" featuring new content and bug fixes.
End-of-Life
When software is no longer sold
or supported, the product is said to have reached end-of-life, to be
discontinued, retired, or obsolete, but user loyalty may continue its existence
for some time, even long after its platform is obsolete—e.g., the Atari ST and
Commodore's Amiga.
Release Management
Release
Management is the process of
managing software releases
from development stage to software release. It is a relatively new but rapidly
growing discipline within software engineering.
As software systems, software
development processes, and resources become more distributed, they
invariably become more specialized and complex. Furthermore, software products
(especially web applications)
are typically in an ongoing cycle of development, testing, and release. Add to this an evolution and growing
complexity of the platforms on which these systems run, and it becomes clear
there are a lot of moving pieces that must fit together seamlessly to guarantee
the success and long-term value of a product or project. The need therefore
exists for dedicated resources to oversee the integration and flow of
development, testing, deployment, and support of these systems. Although
project managers have done this in the past, they generally are more concerned
with high-level, "grand design" aspects of a project or application,
and so often do not have time to oversee some of the more technical or
day-to-day aspects. Release managers (aka "RMs") address this need.
They must have a general knowledge of every aspect of the software
development process, various applicable operating systems and
software application or platforms, as well as various business functions and
perspectives.
A Manager's roles are:
·
Facilitator: serves as a liaison between varying business units to
promote smooth and timely delivery of software products or updates.
·
Gatekeeper: “holds the keys” to production systems/applications and takes
responsibility for their implementations.
·
Architect: helps to identify, create and/or implement processes or
products to efficiently manage the release of code.
·
Server application support engineer: help troubleshoot problems with an
application (although not typically at a code level).
·
Coordinator: utilized to coordinate disparate source trees, projects,
teams and components.
Some of the challenges facing a software release
manager include the management of:
·
Software Defects
·
Issues
·
Risks
·
Software change requests
·
New Development Requests (Additional features and functions)
·
Deployment and Packaging
· New Development Tasks
Impact of Agile Software Development on Release
Management
Agile software
development methodologies have driven radically higher numbers of release
events in organizations where it has been adopted. More release events have
corresponded to increased reliance on release management teams and their
colleagues in IT Operations to track and execute complex application release
processes. Operations teams have used methodologies—such as Information
Technology Infrastructure Library ITIL v3 Book: Service Transition (which
contains a section on release management) to improve their release management
capabilities as they relate to both business applications and internal IT
services. Agile has also driven development and operations teams to collaborate
more closely during production release events—this trend is referred to as DevOps.
Release Management Software
For organizations to
effectively operate a release management function they need to ensure they have
processes and supporting tools. Release management software allows release
teams to plan, manage and control the release schedule and track the status of
each release to ensure production worthiness.
Release Management
software also provides the added benefit of applying central governance and
auditing over releases before decision-makers approve releases to production.
Release Engineering
Release Engineering,
frequently abbreviated as "RE" or "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 is often
said[who?] that release engineering is to software engineering as manufacturing
is to an industrial process. 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, i.e. continuous integration and push on
green initiatives.
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 (i.e. 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 be 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.
No comments:
Post a Comment