Releasing Code

The Release process

The Release process defines the actions required to deliver a software product to an external customer. The external customer is any entity outside the development department. This may be a true (paying) customer, or may be another engineering department, for example Testing or Production.

The Release process is a triggered activity. The trigger events are scheduled as part of project planning. Defining a release is a project milestone which must define

  • What will be released
  • When it will be released
  • Who it will be released to


Release process relationships

The Release process is related to, but independent of, the Change Management, Revision Control and Build Processes.



Figure 21 – Release management is related to, but independent of, the other CM practices

Change Management

Defines the modifications and/or additions to the product, the order in which the changes are incorporated.

Revision Control

Ensures the configuration of the product is controlled and reproducible.

Build Process

Defines how to build the product.

Release Process

Defines the target recipient of the product.


Software release stages

During development the product may be released:

  • To different standards
  • To different customers

The different releases comprise a release lifecycle, with each stage representing an improvement in product quality (Figure 22).



Figure 22 – Each release type represents a different level of quality, and may be released to different customers
Development releases

Development releases are internal releases; usually to (independent) test. These releases are unlikely to be ‘feature-complete’; often the release represents one or more work packages (or, in the case of Agile projects, features or ‘sprints’).

It is not expected that these early releases are perfect. It is likely they have only undergone developer testing. A significant number of bugs can be expected in early releases.

Development releases may be produced at high frequency. Weekly releases would be expected at the beginning of development, possibly rising to daily as the project enters a debug phase.

Alpha and Beta

Alpha and Beta releases focus on usage and/or useability testing. Sometimes these are known as Technical Preview releases. The product may be feature-complete (or close) at this stage. Alpha/Beta releases are relatively stable and should contain no (known) critical bugs.

Alpha testing consists of simulated or actual operational testing. It is normally carried out in-house and performed by non-development users, for example internal proxy-customers (staff acting on behalf of the ‘real’ customers).

Beta testing is also operational testing. It is often performed out-house (that is, outside the control of the development organisation). It is carried out by focus groups, or specially selected users. Very often Beta releases are made available free to existing customers to use and test in their own environment.

It is important not to begin Alpha and Beta releases too early in the development cycle. Although allowing users to test the product is potentially very effective a product with many bugs (particularly in areas of key user functionality) can lead to a loss of confidence in the product that is very difficult to recover.

Production-ready releases

The term Release candidate refers to a version with the potential to be a final product. It is essentially ready to release unless fatal bugs emerge during final testing (or possibly Alpha or Beta testing). The product features all designed functions and no known critical bugs.

A Production release is very similar to a Release Candidate ( in fact, it could be argued the Production release is just the final release candidate!). Any last minute bugs fixed. The Production release represents final product quality and features, and it the release sent to Production engineering.

Glennan Carnie
Dislike (0)
Website | + posts

Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry.

He specialises in C++, UML, software modelling, Systems Engineering and process development.

About Glennan Carnie

Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry. He specialises in C++, UML, software modelling, Systems Engineering and process development.
This entry was posted in Design Issues and tagged , , , , , , , , . Bookmark the permalink.

3 Responses to Releasing Code

  1. Dave Banham says:

    Yes, but by what criteria do we judge a release candidate fit for production? Who should do this?

    Should it be "perfect" or are known defects permissible? Should the possibility of latent (yet to be discovered defects) be considered? Have all of the required engineering process artefacts and metrics be available? Is the end user documentation ready?

    The bottom line is that management should understand the business risks involved in authorising a product release and it is the engineering teams responsibility to make all of the facts about the proposed product (release candidate) version known to them.

    Like (0)
    Dislike (0)
  2. Saud Rehman says:

    Interesting article.
    With software resources becoming increasingly distributed,release management processes will become more important.I was working on Embedded Linux based medical product where platform software from various git repositories far exceeded the application software.Managing the release of such software requires careful consideration and planning.
    By the way What software do you use for creating these beautiful flowhcharts?
    Please share.

    Like (0)
    Dislike (0)
  3. glennan says:


    The flowcharts were done 'the hard way' - the basic boxes were hand-drawn on paper, scanned, then converted to vector graphics. The font is a freely available one called 'Rabiohead' Everything was put together (and animated!) in PowerPoint.

    Like (0)
    Dislike (0)

Leave a Reply