Whereas Build Promotions are logical constructions, an execution represents
the actual execution (ie running) of the actions in the deployment plan for an environment.
In most cases, one execution will correspond with one promotion. Some
situations, however, call for zero or more executions:
- No Executions – it may be desirable to "Skip" actual deployment to
an environment if that environment is unavailable; this would be accomplished
by promoting but not executing. Obviously, this should be done only in rare
- Failed Executions – a second execution may be appropriate if the
first failed as a result of configuration or a temporary outage.
- Rollback – a previously-deployed build may be re-executed in order
to achieve a rollback.
Executions in BuildMaster
After a build has been promoted to an environment, an execution may be
against that environment.
Executions may be run immediately or on a target date. Specifying a date/time
may be useful for off-hours executions.
Note that a "scheduled execution" is different than a "build schedule" in
that, the execution refers to an already-created (but not yet started)
execution, and a build schedule is designed to create a new build, promote it,
and then run an execution for that promotion.
When an execution is started, all of the eligible Action Groups – i.e. those
associated with deployables that have been selected in the release – are placed
in a queue for execution. This queue is sorted by the Action Group's sequence
number, and then each action group is validated (using any associated
predicates) and then run.
Action Groups that share a sequence number may be run in parallel. Because of
this, it is not recommended to share sequence numbers for Action Groups within
the same deployable.
An execution may be canceled before or while it's running. Doing so will halt
the action in progress and, when the action is stopped, fail the execution.
Once completed, the execution overview page provides details of each action
which was performed. In addition, each action has a detailed log of what
occurred while the action was running.
Like builds and releases, all past executions are available on the execution
history page, which chronicles all of the executions throughout all of the
Execution in Progress
An execution that is in the executing status defaults to the "live" view,
which provides a "real time" status on each action as it is executed.
When an execution is requested, it begins in the pending status. It's only
after the BuildMaster service "picks up" the pending execution that its status
changes to Executing.
Once the execution has finished, the final status becomes either Succeeded or
Failed. Note that canceling an execution will give it a failed status.
This content has the following tags: