Demote and roll back in the same operation

If you have the appropriate privileges, you can roll back and demote an object in the same operation.

Roll back on demotion

When you demote an object, it is automatically rolled back from default areas at higher stages. If you have privileges for demoting an object, you are implicitly granted deployment privileges that enable you to perform the rollback. If the rollback cannot be performed, demotion still proceeds.

Rollback and demotion are independent transactions. The demotion occurs immediately, but the rollback is queued and may not succeed.

If the object has been deployed to manual areas at a higher stage, you need to roll back these deployments before performing the demotion. The object is not demoted if it is deployed to manual areas at higher stages. Rolling back from manual areas requires deployment privileges.

Back to top

Manual rollback

If you have deployment privileges for an area, you can manually roll back any deployment as long as the area version that the deployment creates is not depended on by later area versions.

Back to top

View history

To help you decide what you need to roll back and in what order, use the History tab in the Deployment view. The tab has an option that enables you to only show objects that can be rolled back.

For details, see Deployment view.

Back to top

Demote with rollback rules

  • If you have the appropriate privilege for an area, you can choose which default deployment areas of the target (demote to) stage are populated.

  • If the deployment area list is empty and no deployment operation has been requested, no deployment areas are updated on the target stage during demotion.

  • If any files are deployed to non-default areas, a demote operation fails. Under the stage being demoted from, you must manually roll back those files before you can rerun the Demote command.

  • If a rollback from any development areas in the source stage fails, the demotion from the source stage does not complete.

  • Demote automatically rolls back files in any Deploy by Default areas. For details about the Deploy by Default option, see Automatic deployment (Deploy by Default).

  • When you select a deployment area, it must be at the same stage to which you are demoting. For example, if you are demoting from the QA stage to SIT, any area that you select must be attached to the SIT stage. You cannot select an area that is not at the same stage.

  • You do not need any privilege to roll back from default deployment areas, as this privilege is implicit (permission is given automatically if you have the privilege to roll back from the source stage).

  • You do not need any privilege to deploy to default deployment areas, as this privilege is implicit (permission is given automatically if you have the privilege to deploy to the target stage).

  • You need a privilege to deploy to non-default deployment areas, as this privilege is explicit. Because the area is not a default one, you require the privilege on that area before you can deploy to the area.

  • If a rollback and demotion succeeds but then the deployment fails, a warning is displayed. Only the rollback and demote operations are automatic.

  • If you bypass stages during a demotion, all default deployment areas in all bypassed stages are rolled back automatically.

    Example: There are default deployment areas attached to the DEV and SIT stages. You demote from the QA stage straight to DEV, bypassing the SIT stage. Both the QA and the SIT default deployment areas are automatically rolled back.

    The Demote commands are run one at a time. If an intermediate demotion fails, any preceding successful demotions cannot be recovered. All the Demote with Rollback rules above must apply for this rule to be successful.

  • A demote fails if the objects are deployed to a deployment area where Deploy by Default is not enabled. You must first roll back the objects manually.

  • When you roll back from a higher stage, deployment to the lower stage that you are demoting to is optional.

Tip: If you have configuration files that you deploy and then edit, keep them separate from your source code. For example, if you do a rollback but the rollback fails, area recovery reinstates the previous version of the area, and the configuration files are also rolled back to their previous state. This may affect the content of the files.

Back to top

See also: