Most of these options are fairly self-explanatory.
The “latest successful build” is the most recent build excluding any failing builds. So this option will
typically just redeploy the latest version again. If you use this option, you will probably want to select
the “Stable builds only” checkbox, which will exclude any unstable builds as well.
If you have opted to discard old builds, you will be able to flag certain build jobs to be kept forever (see
Section 5.3.1, “General Options”). In this case, you can choose to deploy the “Latest saved build”.
A sensible option for an automated build job at the end of a build pipeline is “Upstream build that
triggered this job”. This way, you can be sure that you are deploying the artifact that was generated by
(or promoted through) the previous build job, even if other builds have happened since. It is worth noting
that, although this sort of parameterized build job is often used to manual deploy a specific artifact, it
can also be effectively used as part of an automated build process. If it is not triggered manually, it will
simply use whatever value you define in the “default selector” field.
You can also choose the “Specified by permalink” option (see Figure 12.8, “Using the “Specified by
permalink” option”). This lets you choose from a number of shortcut values, such as the last build, the
last stable build, the last successful build, and so on.
Figure 12.8. Using the “Specified by permalink” option
However if you want to redeploy a particular version of your application, a more useful option is
“Specific build” (see Figure 12.9, “Using a specific build”). This option lets you provide a specific build
number to be deployed. This is the most flexible way to redeploy an application—you will just need to
know the number of the build you need to redeploy, but this usually isn’t too hard to find by looking
at the build history of the original build job.
Figure 12.9. Using a specific build