|
Delivery Manager is a USoft application delivered by USoft (in the same way as USoft Authorizer, USoft Benchmark, and USoft Service Definer).
Each installation of Delivery Manager helps you deliver 1 specific USoft application of your own (the top-level application), optionally including any modules consumed by the top-level application in the case that you use USoft Definer modular development features.
The best location for each Delivery Manager installation is a place that is easily accessed by all contributors to the top-level application and (optionally) its modules.
Roughly, you have a choice between using a separate database account for Delivery Manager (Option 1), or having Delivery Manager share the database or database account that is used for developing the top-level application (Option 2).
In both options, you also need to think about which physical machine(s) you are going to deliver from.
One option is that you create a database (SQL Server) or database account (Oracle) especially for Delivery Manager. The only tables created in this account will be tables with the prefix T_DL_..., which are the tables used by Delivery Manager.
This is an attractive option if you want to shield delivery capability from some of the team members who have access to application development:
•One reason for this could be role division. Often a USoft team is a relatively small development team that is non-hierarchical, in the sense that all individuals are expected to know how to perform all the core operations, so that the developers are also the people expected to release (deliver) the application. But an alternative setup could be that specific individuals (perhaps called 'release managers') are responsible for delivering developed software. •Another reason could be that you find delivery less error-prone if you have to go to a different database account to execute delivery operations. Some teams prefer to be able to deliver only from the physical server machine where the development repository resides (see the end of this help topic). With this option, team members require a different USoft Binder file for delivery than for development of the application.
With this option, you must still run Delivery Manager with the same USoft patch version than you use for application development. Other patch releases may work but this is not guaranteed, especially when there are repository upgrades between patches.
With this option, the database platform for development may be different from the database platform for Delivery Manager.
|
Another option is that you create the Delivery Manager tables in the same database (SQL Server) or database account (Oracle) where you also deliver the top-level application.
This is an attractive option if you have a number of different top-level applications that you release with Delivery Manager, because it is immediately clear which installation of Delivery Manager corresponds to which top-level application.
Perhaps unexpectedly, in spite of the fact that Delivery Manager is located in the development database account itself, when you set it up you must still explicitly declare the characteristics of this database account (username, password, database platform, database connect string, application owner).
With this option, team members require only a single USoft Binder file to access development and delivery of the top-level application.
With this option, individuals who have access to the development of the top-level application automatically also have access to its delivery, which may or may not be desirable.
With this option, you must run Delivery Manager with the same USoft product version and the same database platform that you use for application development.
|
It is good practice to limit the number of machines that you deliver from, if only because Delivery Manager does not have a locking facility. You need to make sure that multiple individuals do not deliver at the same time, and that developers are not making changes at the time when you deliver.
To minimise this kind of concurrency problems, some teams like to deliver only from the physical machine that acts as the server of the Development environment of your application. This way, to access the USoft Binder leading to Delivery Manager, team members must first log on to that server, for example by using a Remote Desktop application. In this setup it is relatively easier to control concurrency and authorisation.
Others like the convenience of accessing Delivery Manager from each developer laptop, in the same way as all the other USoft applications are accessed and used.
The decision which machines to deliver from depends partly on the specific way in which your different machines have access to the same or different shared file system resources. If you use multiple machines to deliver from, each must have a way to reference the same location of release folders by the same folder paths. This location is declared in Delivery Manager as the root folder.
|
|
