|
A release tree is a folder on a file system that contains deliverables produced by an instance of Delivery Manager. This instance is typically used for releasing all the deliverables connected to a specific top-level USoft application and all the internal modules (if any) that it consumes. Also, typically, this release tree is the only place where these deliverables are written to: it is a hatch through which deliverables are passed to target machines. This hatch acts as a single-point-of-truth for all target machines.
The folder that is the location of the release tree is referred to as the root folder. In Delivery Manager, the Root Folder property is a filepath pointing to this folder. You can view at all times what is the path to the Root Folder. Do this by selecting Release, Current Release from the menu.
The root folder contains one or more release folders which, in turn, contain deliverables.
Assuming that you use Delivery Manager to release deliverables to target machines, initialising a release tree is a logical first step when you start using Delivery Manager for your USoft application.
A Delivery Manager instance can manage only 1 release tree at any one time.
You can re-initialise this release tree at some later time. From that time onward, Delivery Manager will write all deliverables to that new release tree. The folder structure on the file system that corresponded to the previous release tree is not dropped or otherwise affected by such re-initialisation. This contrasts with the effect of reverting, within one and the same release tree, from the current release to the previous release. When you revert, everything associated with the current release is lost.
|
A release tree or root folder contains a collection of 1 or more subfolders called release folders. Each release folder has the name of a version of the top-level application that is released in the release tree. Each release folder has subfolders, each of which corresponds to a section: it is dedicated to a specific type of deliverable. A section folder may itself have subfolders. The number of different sections in a release folder depends on how many different types of deliverable you have, and how many of those you have already released at least once for the version.
In the picture in this help topic, the first release for which the release tree was used was 'TRAVEL-1.4.21'. The 'TRAVEL-1.4.21' release folder contains all the deliverables for this version. You can use any naming scheme for release folders (= versions). For example, this folder could equally have been called '1.4.21'.
Currently, the team is working on a new version called 'TRAVEL-1.4.22'. The picture shows that in the section called 'flatfiles', 10 flatfiles have so far been released, 5 for the top-level TRAVEL application, and 5 for an internal module consumed by TRAVEL that is called MYMODULE.
In Delivery Manager, you can view at all times what is the current release folder, ie., the folder where current delivery takes place. Do this by selecting Release, Current Release. In the example, the current release folder is 'TRAVEL-1.4.22'.
As long as the current release folder remains the same, every time you release new deliverables (for example, new flat files) this action will overwrite any previous deliverables of that type.
|
You can create a new release. This causes a new release version number to become the current release. For example, in the picture in this help topic, the current release is 'TRAVEL-1.4.22'. You can create a new release named 'TRAVEL-1.4.23'. As a result, 'TRAVEL-1.4.22' becomes the previous release.
Creating a new release has the effect of freezing the current release. From the time when you create 'TRAVEL-1.4.23', Delivery Manager will no longer write to the 'TRAVEL-1.4.22' folder: no more changes will be made to 'TRAVEL-1.4.22'. This makes version 'TRAVEL-1.4.22' suitable for distribution to target machines.
This way of working ensures that all target machines have identical deliverables of a given version, even if they don't all pick up that version at the same time.
In a given release tree, Delivery Manager only supports a lineair structure: a single sequence of releases with no side branches. Each release except the initial release has exactly 1 previous version. Each release except the current release has exactly 1 next version.
When you create releases, Delivery Manager does not clean up or archive older releases. Administrators must perform any desired clean-up, archive, and backup procedures by working at file system outside the Delivery Manager application. Delivery Manager does keep a Release Frame record for each past release folder, but for past releases it does not guarantee that a corresponding folder in the file system remains in existence. You can delete Release Frame records for older releases if you like. However, comparison features will work properly only if you keep the previous release folder of the current release intact.
|
You can revert a release tree to the previous release.
The only intended use of the Revert option is to go back to the previous release if you have made some mistake. For example, you can revert if you have just started a new release but you have changed your mind about the ideal name of this new release. Reverting to a previous release is not normally part of a typical release process.
When you revert, Delivery Manager removes everything associated with the current release and then automatically qualifies the previous release as "current". You could go all the way back to the initial release by repeating the Revert action, and lose your entire release history in the process. However, to start over with an initial release, it is generally better to re-initialise the release tree. See the top of this help topic for this operation.
|
See Next
Release properties
|
