Properties

You can set properties for many different elements, including components, environments, processes, and applications. You can also set global properties for the system.

You set properties on these IBM® UrbanCode™ Deploy elements to achieve four primary goals:

To store secure values that are required for deployments artifacts, but which must remain encrypted in the user interface and logs
To provide information that differs to various environments or components
To provide property values to other processes, resources, and steps
To set system variables

To deploy applications, installing components on a target computer might require IDs and passwords that must remain secure. The user interface might display this information and testing and debugging might require log reviews. The property can contain the ID and password information, but displays in the user interface and entries in logs show asterisks (*) in place of the actual characters.

For example, you plan to deploy a WAR file to a Tomcat web server. To deploy the file, one of the process steps must log in as admin user with permissions. To maintain the privacy of the login credentials, you use a secure property for the password, and then you refer to that property whenever you need to enter the password: p:property_name=password. Whenever the property value, the password, is included in logs, it is obscured by four asterisks (*).

Different environments require specific elements and processes, which can make automating deployments difficult. With properties, however, you can provide the correct information to each set of components in each environment, thus facilitating automation. An environment might use different properties.

An application might have a number of environments that you deploy to. Each of these environments might configured differently. Environment properties provide configurations for the different environments. For example, an environment property can map to different ports as required by the target computers for applications that run on different ports and that communicate with different databases.

In complex processes and deployment scenarios, you want to automate as much as possible. Passing property values among processes, resources, and steps helps limit the requirement to provide input manually and to maintain accuracy and reliability. You can refer to output properties from one step to another. Consider this flow and possible step output:

Before you deploy a version, you want to compare artifacts that are part of the deployed version and part of the version to be deployed.
You use a step that sets the ID and the names of the different versions as step output.
By using the output properties, you download the artifacts for the specific, required version.
The steps check for the ID and version name of the currently deployed version.
The steps check for the ID and version name of the next version to be deployed, thus ensuring that the correct versions are targeted and deployed.

Properties are flexible, and you can apply them to processes, environments, components, and even the system. Keeping track of what properties are set where and on what element can present a challenge. One way to meet that challenge is to set system properties that apply to all situations. Of course, you must be judicious in setting system properties so that you can be flexible in applying properties to other elements. When you want to define a property one time and have it apply to all situations, the system property reduces set up time.

Assume that you have one Maven repository for all your code. You might refer to the address for this repository 100 times. You don't need to set the address for this repository more than once. You set a system property, for example: maven.repository.url=/theURL/. In most places in a deployment process, use this property and the actual address is used. If the address of the Maven repository changes, you can universally change all references by making a single system property change.

Feedback