Reviewing your development platform

TIP 1: If you use multiple development computers, use the same USoft patch on each of these machines at any one time.

TIP 2: If you use multiple development computers, consider installing USoft in the same local folder on each machine.

TIP 3: Avoid having more USoft installations on a given machine than you absolutely need at any one time. 1 installation per machine is the ideal.

TIP 4: Prefer official patch releases. Avoid using non-official USoft dayversions if at all possible. If not, switch to the next patch as soon as possible.

A USoft installation is the result of running the USoft Setup routine. This routine installs the USoft product on a computer. Physically, a USoft installation is a set of executables and other files in a local folder of your choice, for example:

c:\Usd90

c:\Program Files\Usd90

From a management point of view, there is often no good reason to let team members choose their own local installation folder. It is especially attractive to have everybody use the same local installation folder if you also use this as a synchronisation folder. For details, see Step 4 in this help topic.

The USoft product is released in official patches that carry names like:

9.0.1M

An important limitation of Delivery Manager is that it is not guaranteed to handle differences between patch releases if repository changes have occurred between those patches. This has consequences if you have multiple USoft installations on a single machine, but also if you have multiple development machines. Valid reasons for having multiple development machines include:

•Multiple developers who use their own physical PC or laptop but connect to the same shared USoft repository.

•Different development environments or teams for different modules of your application.

•Having Delivery Manager run from a different machine or database account (or both) than the USoft development tools. There are arguments for and against this.

One capability of Delivery Manager is to log on to remote database locations and carry out standard USoft operations there. These include generating flat files, publishing web pages and REST servers, and exporting metadata or application data to file. These remote operations are automatically carried out against the local USoft installation that Delivery Manager uses itself. This is the USoft installation located in the folder identified by the result of the query:

select RulesEngine.GetProperty( 'SystemDir' )

TIP 1: Create a shared release folder or folder drive that all developing team members have read-write access to, for example:

D:\Releases

\\fs.mycompany.com\Releases

If you have multiple developers, Delivery Manager release management works best if they all release their work to the same common location. This is comparable to a production tree in a version management tool such as .Git.

TIP 2: If you use Publication Configurations in Web Designer, make sure to place the Alternative Template Folder ("Alt folder") in a subfolder of the shared release folder:

D:\Sources\Alt

\\fs.mycompany.com\Sources\Alt

In Web Designer, the Alt Folder is a source element in the same way as the Web Designer database records: the publication process draws on a combination of the two. In the same way as developers share the repository records, they should be sharing a single instance of the Alt folder.

TIP 3: For the following path attributes in USoft tools, use a local path, for example:

C:\Publications\MyPublication

•Publication Folder Paths for servers in USoft Service Definer.

•Publication Directories for Publication Configurations in USoft Web Designer.

•Synchronisation paths for consumed modules in USoft Definer (you can view and change these paths by choosing Tools, Manage Internal Interfaces, Consumed Interfaces from the USoft Definer menu). See also Step 4 in this help topic.

The reason why it is good practice to use a local path for these purposes is that, in a Delivery Manager context, these paths become relatively unimportant. They enable development-time testing and debugging, of course, but otherwise they only serve as interim locations from where the deliverables are released to the release folders (TIP 1), their final destination. You create clarity for the team by having local interim folders, as opposed to shared destination folders.

TIP: Have a policy in place for naming versions of your application, including naming the versions of all modules (if any).

When you use Delivery Manager, you must name each application version that you plan to release. It is customary to use names like the following for major releases:

1.0

1.1

and names like the following for minor (or patch) releases:

1.0.5

1.0.5F

but you could use any naming policy that suits you, including names such as

1.1 Beta

In Delivery Manager, the name of your application version is automatically also the name of your release and your release folder.

When you start using Delivery Manager, you must decide what is the first application version name that you want to release with it. You are asked to supply this version name when you initialise the release tree.

All this applies only to the versioning of the top-level application. If your application is made up of USoft modules, you must designate exactly one of these as the top-level application. In general, in USoft, any module can consume any other module. A consumed module can, in turn, have consumed modules of its own, even if the latter are also directly consumed by the top-level application. All these possibilities are supported by Delivery Manager, but Delivery Manager does not represent module structure in this way: it only keeps track of which module is the top-level application. The remaining modules are called modules proper by Delivery Manager, and they are seen as a non-hierarchical list.

In contrast with the top-level application, Delivery Manager does not force you to register the version of each non-top-level module. A module should have its own versioning. You can manually register in Delivery Manager what version of a given module is shipped with a given module of your top-level application, but if you start doing this you must keep up the discipline. Module versions do not surface in deliverables released with Delivery Manager.

TIP 1: If you have a consumed module that changes frequently, is mainly (or only) used by your top-level application, and/or is mainly developed by the same people as the top-level application, then consider setting its synchronisation folder to the local installation folder. For local installation folder tips, see Step 1 of this help topic.

Synchronisation folders are locations used for synchronising an application or module with a consumed module. You can view and change synchronisation folders by choosing Tools, Manage Internal Interfaces, Consumed Interfaces from the USoft Definer menu.

By setting synchronisation folders to local installation folders, you create a shortcut: for operations that require module flatfiles to be found in the installation folder, such as running the client/server User Application with synchronised modules in Development, or running Fill Authorizer Tables in USoft Authorizer, you no longer need to copy the flatfiles from the synchronisation folder to the installation folder. Without Delivery Manager, you could have a reason to run with a previous version of a module, but this is difficult and error-prone to manage, because versioning is not apparent from the name of a flat file. When you use Delivery Manager, all versions of all flatfiles are visible in the release folders, so it is easy to revert to a previous version if you have to.

In this scenario, deliver modules by letting your instance of Delivery Manager log on to the development repository of the module, re-generate the module flatfiles, and copy them to the release folder.

TIP 2: If you have a consumed module that serves many other applications apart from your top-level application, or that is maintained by a different team or at a very different pace from your top-level application, then consider setting its synchronisation folder to a source folder on a shared drive. The other team could release their module to this shared drive using some remote procedure, such as a distinct instance of Delivery Manager. In this scenario, instead of letting Delivery Manager log on to the development repository of the module and re-generate flatfiles, you could let it copy the module flatfiles found in the shared folder to the release folder.

See also Delivering modules.