A rollout consists of the distribution set and a target-query-filter which defines the targets to be updated in this rollout. The targets within this filter are split up in configured amount of Deployment Groups at creation time.
When starting a rollout, for all targets within this rollout deployment actions will be created. The deployment actions of the first group will be started immediately after all other deployment actions will be scheduled.
Since rollouts might include a large number of targets and deployment groups, creation as well as starting a rollout might take some time. Therefore, the creation and starting of a rollout is executed asynchronously. The creation and starting progress is reflected by the rollout’s status attribute.
The targets reflected by the target-query-filter are interpreted at creation time. Only targets which have been created at that time are included in the rollout. Targets which are created after the rollout creation will not be included. At rollout creation time all deployment groups defined by the amount groups or the groups definition will be created. A scheduler will fill the deployment groups one after another with targets according to the group’s target filter and target percentage. Dynamically adding targets to a created or running rollout is currently not supported.
A scheduler checks in a defined interval all groups that are in the CREATING state. The deployment groups have a defined order in which they are processed one after another until all have the READY state.
A group has an optional target filter that can be used to select a subset of the targets in the Rollout and a target percentage that can further reduce the amount of targets in the group’s subset. During the filling process only targets that are not yet in one of the previous groups are considered.
To divide 30 targets into two groups the first group would define a target percentage of 50, which will add 15 targets to it. The second group would define a target percentage of 100, which will add the remaining 15 targets.
The rollout is using the same concept based on deployment actions per target. All necessary deployment actions will be created in scheduled state at starting point. Once all deployment actions have been scheduled, those of the first deployment group will be started and set to running.
If targets having unfinished deployment actions at rollout starting time, these actions are tried to be canceled (state: canceling). Scheduled actions from another rollout are canceled directly on server side because they were never running before and can be safely canceled.
Multiple rollouts can be running at the same time, but if the rollouts effect the same targets they will interfere the targets deployment actions e.g. canceling/cancel already running/scheduled deployment actions.
A success condition defines when a deployment group is interpreted as success and triggers the success action. E.g. a threshold of successfully updated targets within the group.
The success action is executed if the success_condition is fulfilled. Currently only the success action starting the next following deployment group is available.
An error condition defines when a deployment group is interpreted as failure and triggers the error action. E.g. a threshold of update failures of targets within the group.
The error action is executed if the error condition is fulfilled. Currently only the error action pausing the whole rollout is available, a paused rollout can be resumed by a user.
It may take some time before a rollout is processed, or the next deployment group is started because the rollout is manged by a scheduler task.
It is possible to delete Targets that belong to a Rollout. There will be no user hint when this is done. This will lead to the following behavior: