PDM

Rollout and outcome ​

Once you press Start release, all further work happens on the server and is shown as a workspace — a long-running operation broken down into individual steps with their own statuses, logs and results.

What happens, step by step ​

The order of the steps is the same for every release:

  1. Preparing the values. A final value is prepared for every changed field. If a service action was selected instead of a value, a build is run first and the tag of the built image becomes the value of the field.
  2. Updating the default values. The new values are written to the shared platform config — the one that applies to every stand without settings of its own.
  3. Writing the stands. For the stands where you reset the overrides, their new values are written. Stands where you chose Keep are not touched at this step.
  4. Committing the changes as one. All the records are saved as a single change: either everything is saved or nothing is.
  5. Mass-apply. The rollout to production stands is started — this is the step that delivers the changes to the running environments.

Following the progress ​

The workspace page opens right after the start. There are two ways to get back to it later: through the Workspaces section, or from the release row in the release history via the Open the processing pipeline → link.

The page shows all the steps with the state of each one, the links between them, and for every step its input and output, its logs and its error text. For more on how the page is built, see Running and watching.

A build step can hang around for a while

If the release includes a build, PDM waits for the pipeline to finish and polls it every few seconds. A step sitting in the Running state for tens of minutes is normal for a long build, not a sign of a hang. The panel of such a step has a direct link to the pipeline and its log.

How to tell that everything has been applied ​

  1. The release status. In the release history the row should end up with the status Completed. Running means it is still going, Failed means it stopped on an error.
  2. The last step. On the workspace page the mass-apply step must be in the Completed state — it is the only one that delivers the changes to the running stands.
  3. The values on the stand. Open the stand in question, go to the Services tab and check the value of the field. Keep in mind that PDM shows the state received during the last synchronisation, so fresh values do not appear there instantly.

A release record is not the same as success

A release enters the history the moment it is started, before it runs. A row in the list says that the release was started, not that it arrived. Go by the status and by the last step of the workspace.

If some of the stands were not updated ​

Start by looking at the workspace page to see which step exactly things stopped at and what its error and logs say.

Typical cases:

What you seeWhat it meansWhat to do
The build step failedThe pipeline finished unsuccessfully, the field value was not producedOpen the pipeline through the link on the step, sort out the build and start the release again
The write step of a particular stand failedThe configuration could not be written for that standCheck whether the stand is reachable and whether it has synchronised; PDM cannot write the config of a stand it has no synchronisation data for
The mass-apply step failedThe changes have been written, but the rollout to production stands did not go throughShow the error to the operations team; the changes are already committed, restarting the release is not needed to preserve them
A stand stayed on the old value, with no errorsThe stand has a value of its own and Keep was chosen for it at the Overrides stepChange the value on the stand itself, or make a new release that resets that override

A few important facts about how a release behaves on failure:

  • The changes are written either in full or not at all — there is no such thing as a partially written set of values.
  • There is no automatic rollback. To bring the previous values back you need a new release with the old values, or a manual edit of the specific stand.
  • Stands the release was not supposed to touch are not changed when it fails.

Where to see what exactly changed ​

  • The release history. The release row shows the parameter, the service and the “before → after” transition for every changed field — that is, the contents of the release itself.
  • The workspace page. For every step you can see the values it worked with on input and what came out.
  • The stand. The Services tab of a particular stand shows which value is in effect on it now and whether it is overridden.

See also ​