Figure 10.43. Configuring a build promotion process
Let’s look at configuring the automated promote-to-test build process.
The first thing you need to define is how this build promotion process will be triggered. Build promotion
can be either automatic, based on the result of a downstream build job, or manually activated by a user.
In Figure 10.43, “Configuring a build promotion process”, the build promotion for this build job will
be automatically triggered when the automated web tests (executed by the phoenix-web-tests build
job) are successful.
You can also have certain build jobs that can only be promoted manually, as illustrated in Figure 10.44,
“Configuring a manual build promotion process”. Manual build promotion is used for cases where
human intervention is needed to approve a build promotion. Deployment to UAT or production are
common examples of this. Another example is where you want to temporarily suspend automatic build
promotions for a short period, such as nearing a release.
Manual builds, as the name suggests, need to be manually approved to be executed. If the promotion
process is to trigger a parameterized build job, you can also provide parameters that the approver will
need to enter when approving. In some cases, it can also be useful to designate certain users who are
allowed to activate the manual promotion. You can do this by specifying a list of users or groups in
the Approvers list.