Some More Advanced Examples

DropZone Deployments
In some customer's environments the production systems may well be maintained by a third party. This inevitably means that the development team will not have direct access to the production server in order to make a deployment. This situation is typically handled by making the deployment to a dropzone and notifying the third party that there is a new deployment in the dropzone. This is fairly easy to achieve with Deployment Manager. With a little bit more work it is even possible to generate a set of deployment instructions for the third-party to follow, listing all the scripts to apply and in what order.

Optional Deployments
Having given your developers control of their deployments, you may well find that they want to perform an optional step as part of some of their deployments. For example they may wish to deploy a set of debug libraries to assist with fault finding. By utilising Trilogy dialogs we can very easily add a checkbox to the deployment dialog and then make use of this with a conditional expression in a Deployment Manager action.

Giving Even More Control to Developers
When an application is undergoing rapid development changes, it is often the case that the deployment mechanism needs to change to keep pace with those changes. With a centralised configuration file there is just one place to make these changes, but keeping track of those changes can be difficult. Deployment Manager provides a handy feature to help with this - the configuration file can be held in SCM and retrieved automatically each time a deployment is made. Devlopers can then make changes to the configuration themsevles and commit them to back to SCM. It is even possible to make use of the states within the development lifecycle so that configuration file changes can be walked through the lifecycle in sync with the code that they deploy.