Build & Deploy Projects
- Karl Henselin
- Chandresh Patel
- Emily Simon
- Joel Wenzel
To build, deploy or execute a project, open it and go to the execution tab.
When using the list view, project activity is sorted by requested time in descending order.
Building a Standard Project
From the Execution tab, click the Build button.
Select the Environment, Branch, and optionally Release, Change Numbers, and Work Items. If you have enough permissions, you can also open the advanced section and select a different workflow version. The currently active workflow version is the default.
Click Submit to start the build.
Deploying a Project
From the Execution tab, click the Submit Deploy Request button in the row of the project version that you wish to deploy. This is the same for standard and package-based projects.
The version will be filled in based on which row you initiated the deployment from, but can be changed. When initiating a package-based deployment from the project’s main Execution tab, multiple versions of different packages can be deployed at once.
Make sure to select the correct environment and target group(s) that you wish to deploy to.
If the project was already successfully deployed, click the Force Deploy check box.
If you want to schedule the deployment, you can find that option in the Advanced section.
Click the Submit button to submit the deployment request.
Building a Package-Based Project
Package-based projects have an extra tab called Packages. This tab allows you to define groups of files that will be built and deployed together.
If there are inactive files within the package, they will be ignored during the build process and excluded from the artifacts. However, if a file is deactivated after the package has been built, the inactive file will still be deployed unless the package is rebuilt and a new version is deployed.
The screenshot below shows a Salesforce project with several packages in it.
Open a package to view and modify its contents.
Files can be added to the package either from the file list or by adding an SCM revision. If you add by revision, all files that were added or modified in the selected revision will be added to the package.
Files can also be removed from the package on the package files screen.
Once the package contains the right files, you can build and deploy it from the Execution tab. It’s easiest to do it on the Package Execution tab, where you will only be shown executions of your package, but the main Execution tab works too.
Select the correct Environment and Branch, and optionally a Release, change number, work items, and the workflow version in Advanced. Check Force Build if you have built from the same SCM revision in the past and want to build it again. Click the Submit button to start the the build.
Re-build, Re-deploy, or Re-execute a Workflow Execution
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.
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 are not force deployed, so individual files or the entire deployment could be skipped. If there are no changes to deploy, the status of the execution will be displayed as Skipped (Already Deployed). Keep in mind for SCM-based projects, this change detection is based on SCM revisions and not just project versions selected during 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
From the Execution tab, click the Execute button.
Fill in the values of the Environment and the Target Groups you wish to execute the utility on. Optionally enter change tickets or a start time in the advanced section.
Click the Submit button to submit the execute request.
Testing a Project
From the Execution tab, click the Test button.
Enter the Environment and Target Groups to run tests on. Optionally enter one or more test names or tags separated by comma to execute only those tests or tests matching those tags. Otherwise all tests that meet the filter criteria of the environment and target group will be executed.
@Since 7.0.0.2 - If testing a package-based project, package name must additionally be selected to specify which package to test. The package selected must have already been deployed to the the selected Environment.
Click the Test button to start the test.
@Since 7.0.0.1
Suggestions for the Test Name field are supplied from project test configuration YAML and YAML files located in the
/artifacts/fdtestsdirectory of the latest successfully executed deployment.Tags can be set on test cases for the project test configuration. The Tags field can be used to filter and run only the tests with matching tags. If left blank, all tests that meet the filter criteria of the environment, target group, and test name will be executed.
If both test name and test tag are specified we will consider an intersection between them.
Monitoring Project Workflow Requests
Once a project build or deployment request has been submitted, the request status can be monitored by clicking on the Request Id.
The request shows data that was available when the workflow request was created, and doesn’t rely on the workflow having started to show up.
Read more about the Project Workflow Request.
Monitoring Project Workflow Execution
Once a project build or deployment request has been submitted, it can be monitored by clicking on the Execution Id.
The pages changes as the workflow runs. You can see the details in the screens on the left.
Read more about the Project Workflow Execution.
Related content
- style