Urban Deploy is the latest, bleeding-edge deployment tool created by Urban Code, the same creators of Anthill Pro. More information about uDeploy can be found here:

Since this is such a new tool, with perhaps about 9 months on the market since the date of this post. There are some features of this tool that are not documented so well. I’ve been working with it, in an attempt to migrate deployment workflows out of Anthill Pro into uDeploy. The primary reason for this is because uDeploy provides something very specific that Anthill Pro does not. The means to connect singular versions of deploy-time components into what is referred to as a ‘snapshot’. Some people call this component based deployment. The general idea is that my application consists of a collection of components, each with their own versions and configurations. I want to be able to change any of these versions of these components and elegantly deploy them to test and see if they are going to work together. I also want to add and remove additional components. In order do this well, you would need to either use uDeploy, get very fancy with AnthillPro (which we’ve done) or write your own mechanism (which I’ve done, but I prefer uDeploy at this point).

As the effort moves forward using uDeploy, we see lots of variables being used in the application. I wanted to have a list of all the predefined vars, and I was luckily able to obtain one, right from the horses mouth. Here it is:


${p:} – Process properties. Defined on the process’s “properties” tab, given values by whoever is running the process.
${p:component/} – Component custom properties, set on the component’s “properties” tab.
${p:environment/} – Environment properties. These come from two places. You can define properties on the component’s properties tab, under the Environment Properties table. You then give values for these on each environment using the component. In addition, you can set custom environment properties on the environment’s properties tab. These custom properties will override the properties coming from components, although it’s recommended to avoid having the same name in both places.
${p:resource/} – Resource properties. This can include the built-in agent properties as well as any custom properties. Each of these have their own tab on the resource.
${p:resource//} – Resource role properties. These are defined on resource roles, and the values are set when you add a role to a resource.
${p:application/} – Global system properties. These are set on the “System Properties” page in the Settings area.

All of the following are comma-separated series of name=value, including each property on the given object.