Overview
The releases manager is responsible for producing releases of current and legacy releases. It is able to do this irrespective of source control method (in conjunction with the buildsystem).
The release manager uses the buildsystem, but it is seperate from it. The buildsystem is versioned per release, but the latest release manager is used to produce old releases.
Technology
The releases manager is a set of python scripts capable of checking out a buildsystem, and running it. It provides to the buildsystem the capability to checkout new modules from source control.
Releases are stored in an xml file, which holds information such as external name, internal name, version, version status, version control tag name, and build step.
Releases can then be created in one step from the command line, through a command such as
where ArmyOfDarkness is the internal build name.
Advantages
- Legacy versions can be built in one step, without need to checkout anything (assuming you have the release manager checked out).
- You cannot build using the wrong buildsystem for a given release
- All steps of the build are controlled by the buildsystem (including what modules need to be checked out), so the only information that needs to be stored is that which is directly relevant to the release manager.
- By removing the source control implementation from the build scripts, moving to a new source control program (ie: from cvs to subversion, tla etc.) will not prevent the ability of building legacy releases from the NEW source control repository, assuming history has been maintained.
- By specifying a branch instead of a tag, you can have a 'bleeding edge' release
Future improvements
Allow parameters to be passed into the buildstep function. For example, the website buildsystem requires a destination to copy files to, whether it is a local copy, or a remote ftp location. The release manager should be able to pass in build specific parameters to the buildsystem.