To build, deploy or execute a project, open it and go to the execution tab.

Open

Building a Standard Project

From the Execution tab, click the Build button.

Open

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.

1. 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.

2. Make sure to select the correct environment and target group(s) that you wish to deploy to.

3. If the project was already successfully deployed, click the Force Deploy check box.

4. If you want to schedule the deployment, you can find that option in the Advanced section.

5. 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.

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.

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.

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.