Set Up Build Promotion

Define promomotions

Build Promotion can be defined in promotion setting page of a configuration like below:

The promote condition controls whether or not the promote action appears on the build page. Taking above screenshot for example:

1. if a build is successful, the promote action deploy will be visible while promote action release will not be visible like below:
   
2. if a build is recommended, the promote action deploy and release will both be visible like below:
   
3. if a build is failed, no promote actions will be visible.

Revision promotion and file promotion

During a promotion, QuickBuild will remember the repository revision used in source build, and use it to build destination configuration. This is called revision promotion, and it guarantees that the source build and destination build use the same set of source code. Please note that revision promotion only happens for repositories of the same name. For example, if source build is generated using source code from repository "A" and "B", and destination build is generated using source code from repository "B" and "C", only revision of repository "B" will be passed from source build to destination build.

In many cases, you may want to reuse artifacts generated in source build instead of build it from scratch when do the promotion. This is called file promotion and QuickBuild supports this via file to promote setting in a promotion definition:

Specified promote files will be retrieved from source path under publish directory of the source build, and send to destination path under workspace of the node running master step in destination configuration. Then you can define various build steps in destination configuration to further process the artifacts, for example to deploy them to test/production servers.

Control promotion process with variables

Variables can be defined in promotion definition to control the promotion process. For example, you may have the destination build using the same version as source build following below steps:

1. Specify next build version of destination configuration in general setting as ${vars.get("promoteVersion")}.
2. Define variable promoteVersion in promotion definition and set the value to ${build.version}.

If you would like version of destination build being prompted in the above example, you may leave value of the variable promoteVersion empty, and specify its prompt setting as prompt as text input.

At last, if you want to make sure that certain variables in destination build use the same value as in source build, you may define these variables in promotion definition to use the value \${build.getVarValue("<name of the variable>")} . Assume below case:

Variable branch is set to prompt for user input in source build, and it is specified as 1.0 bugfix when source build is triggered. At promotion time, you do not want this variable to prompt for input again, instead, you want the destination build to use the variable value already specified for source build. You can achieve this by defining variable branch in promotion destination, and specify the value as ${build.getVarValue("branch")}.

Permission control

Promotion permission can be controlled by promote condition. For example, if you want that the release promote action is only visible to release managers on recommended builds, you may define the promote condition like below:

warning

Please make sure that the Release Manager group is assigned with PROMOTE_BUILD permission over the configuration; otherwise, all promotion actions will not visible to the group. Refer to Configuration Visibility and Permissions for details.

Auto promotion

Promotion can be marked as "auto promote" as below if you want it to take place automatically when specified condition is satisfied after current build finishes.

If you have a big workflow taking considerable time to run, it is suggested that you divide them into smaller parts and connect them with auto-promotions to achieve below benefits:

1. You can get build feedback as soon as possible.
2. In case of a build failure, the workflow will cease at the failure point, and you may later restart the workflow from the failure point.

Change detection during promotion

In a build promotion process, changes of destination build are calculated by comparing repository revision of current destination build against previous destination build, instead of previous source build. This is well explained [here](Promote Build.html#PromoteBuild-buildchanges).