The Latest

In this article Brad Appleton delves into the realm of build status accounting to discuss various build promotion models and how to choose an appropriate and effective implementation of a build promotion lifecycle.

The first thing that comes to mind about release management is how frequently releases are made and their levels, i.e. full release or patches. A common understanding of Release Management is that it is the management of introducing controlled items into a production (live) environment. But in reality release management is much more than this. “Release management is the process of planning, building, testing and deploying hardware and software, the version control and storage of software.” (British Educational Communications and Technology Agency, release management, Retrieved from http://www.becta.org.uk/tsas/index.cfm?refsect=ntss&bcsect=default§=release&id=tt5281 ) release management is not just what goes into production but also how something goes into production. It is the complete management of your production environment.

This article addresses detailed scenarios and the associated problems with the build process. We look at the usually activities and work patterns of a developer and relate those to build practices.

When I look at the prospect of a distributed development effort, it scares me. So much depends on having the right people and good communicators, all in the right places. It also depends on the successful merging of cultures, but more and more distributed development is taking place.

Many in the software engineering world consider build, package, and deploy the core areas of configuration management (CM). To highlight this, many CM jobs are titled “build engineer” or “release engineer” with responsibilities that focus on the tasks of building, packaging, and deploying releases.

CM is complex enough without having to worry about managing releases! Release management, however, isn't just part of CM, it should be driving your CM solution.

Release management deals with defining, using and managing the set of deliverables (the Build), for all of your customers. This includes the creation of records to subsequently identify release contents, the creation of variant builds, patch releases, incremental releases, and the support of parallel streams of releases (older product releases, current release(s) and future releases). It also deals with the ability to know what’s in a release and to compare one release (e.g. one being sent to a customer) to another (e.g. the one the customer currently has so that the customer is well aware of the changes being made to his environment and how they match up against his requirements). In an end-to-end product management environment, release management spans the entire spectrum from requirements management through to product retirement.