Set Up Build Promotion

Version 2 by Robin Shen
on Aug 19, 2010 08:08.

<< Changes from 1 to 2

compared with

Current by Robin Shen
on Aug 19, 2010 15:01.

Key

These lines were removed. This word was removed.

These lines were added. This word was added.

View page history

There are 9 changes. View first change.

-[Build promotions] can be defined in promotion setting page of a configuration like below:
+[Build promotion] can be defined in promotion setting page of a configuration like below:
-Once it is enabled, a promote button will appear on the successful build screen (please note that if _recommended only_ option is checked when enable the promotion, the promote button will only appear on the recommended build screen). Be aware that, during the promotion process, the repository used in source build will override the repository used in destination build with the same name. This won't be a problem if the source build and destination build uses the same set of repositories.
+# if a build is failed, no promote actions will be visible.
-h1. Control promotion process
+h1. Revision promotion and file promotion
-Variables can be defined in the promotion setting screen to control the promotion process. For example, you may have the destination build using the version as source build if:
-# The property _next build version_ of destination configuration is specified as _$\{vars.get("promoteVersion")\}_.
-# A promotion variable is defined in promotion setting of the source configuration, with the name set to _promoteVersion_, and value set to _$\{build.version\}_.
+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:
+!file-promotion.png!
+Specified promote files will be retrieved from source path under [publish directory|build publish directory] of the source build, and send to destination path under [workspace|configuration 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.
+h1. 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:
+# Specify _next build version_ of destination configuration in general setting as _$\{vars.get("promoteVersion")\}_.
+# Define variable _promoteVersion_ in promotion definition and set the value to _$\{build.version\}_.
-h1. Define multiple promote destinations
+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")\}_.
-For simplicity reasons, QuickBuild only allows to define one promote destination by default. However, you can define multiple configurations with the help of scripting and variables. Below screenshot demonstrates this:
-!promotion2.png!
+h1. 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:
-In this screenshot, the configuration path is defined to take value of promote variable _destination_. At the same time, the variable _destination_ is defined to display a selection box having the user choose the promote destination when the promote button is pressed. In this way, multiple promote destinations are defined and can be selected at promote time. You can also make the _destination_ prompting for a text field, if you want to specify arbitrary configuration at promote time.
+!permissions.png!
+{note}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.{note}
-h1. Change detection
+h1. Change detection during promotion