...

Sometimes during the course of development it is helpful to redo a specific build, deploy, test, or utility execution. In the case of packages, developers will be updating files and refining the package over time. You can click the re-build/re-deploy/re-execute icons on a row to bring up the corresponding request form with the values from the chosen workflow execution filled in. This helps create new build, deploy, test, or utility requests quickly based on the current workflow execution's parameters.

...

Rolling Back a Deployment

If an issue arises with a deployment and you decide it is necessary to revert a project or package to a previous version, you can initiate a rollback deployment. Select the Rollback icon on any Deploy row which is the latest deployment of a project or package to a given target. This will launch a request form similar to a deploy request with an additional Files step (for package-based projects) where you can choose how you want to roll back each file, including how to source each file and which version to roll back to. Rollbacks go through the same schedules, approvals, and notifications that are defined for normal deployments.

Before submitting a rollback request, you must provide Notes. This field is mandatory for all rollback requests, and it is available for all workflow request types. The note can be reviewed later in the project execution history or in reports.

Image Added

...

File Options for Rollback

There are various options to control how files are deployed as part of a rollback execution. The files displayed, along with their order, is the same as the order they were built and deployed. Each file also has the following listed:

• Status Display - The icon next to the file path shows the status from the last deployment of this file. Hover over the icon for more details.

• Delete - Certain project types support marking files to be deleted as part of a deployment. If supported, there is a Delete column to enable or disable this option.

• Rollback Source Type - Define how you want to source each file for the rollback execution. This is an attribute on each file. The default value and list data can be customized from the Project Types screen. These are the default options:

  • Project Version - Source from a previous project version artifact

  • SCM Revision - Retrieve from project's configured source control system

  • Rollback File - Build and deploy a different project file to roll back

  • Backup Repository - Restore from a previous backup version

• Rollback Value - Choose a version to roll back to based on the source type selected. If Rollback File was selected, this dropdown allows you to choose the associated project file to build and deploy in order to roll back the original file. If the version chosen has no changes to deploy, the file will be skipped. Rollback executions are not force deployed.

• Actions - Choose to skip rolling back any file by selecting the skip button. To add it back, select the add button.

Rollback Execution

When a standard project rollback request is submitted, a deployment of the selected version will be initiated.

When a package-based request is submitted, a rollback package will be created with the name ‘Rollback - <Original package name>, or updated if it exists already. This package is automatically completed once the package is successfully rolled back. The rollback package will go through a build to collect the requested file versions from artifacts, backups, or the project’s SCM repository and create an artifact. Then, a deployment is automatically initiated to complete the rollback.

Rollback deployments run the project’s configured deploy workflow. The variable FDDPLY_IS_ROLLBACK is available for use in workflows to customize any steps that may be different in your deploy workflow when running a rollback.

Executing a Utility Project

...