Deploy to organization

The Deploy to organization functionality is dedicated to an effortless migration of changes from one Salesforce organization to another.

In The Welkin Suite, you have all the necessary tools for migrating changed components between your orgs as well as you can also just validate your changes without affecting an org — this option will help you to figure out if your code is absolutely ready for deployment and doesn't cause any issues.

How to start a process of deployment to an organization

There are two ways to start a Deploy to an organization process:

  • the Main menu: Project ⇒ Deploy to organization,

Deploy to organization from the Main Menu

Deploy to organization from the context menu

The Deploy components to organization wizard

Regardless of your approach of starting deploying to an org, after this action, you will see the Deploy components to organization wizard. This wizard will guide you through the deployment process step-by-step.

Entering the credentials

On the first step, you need to select the environment type (Production / Development Edition, Sandbox, or Custom Domain), and enter the credentials of the org where you're going to deploy components: a username, password, and a security token.

Deploy credentials page

Salesforce environment, Username, and Password are required fields while the Security Token is optional: only if you have configured the org to allow logging in without the Security Token, you can omit the Security Token.

Clicking on the Next button will start the validation of the credentials that you've just inserted. If the validation fails, you'll see the error message. Click Back to correct the credentials on the previous page.

Validation fails

Configuring a deployment plan

When the validation of the credentials is successfully passed, on the next page you should select the components that need to be deployed. The Welkin Suite retrieves metadata information from the target org and displays a high-level comparison of organizations content with your local project in a table below with the following columns:

  • Action — deployment action which will be applied to the item,
  • Type — metadata type of the item,
  • NameAPI Name of the item.

Deployment plan

The initial comparison is performed in the high-level mode which means that The Welkin Suite only takes into account existence of different items in the local project and on the target organization. In the high-level comparison mode Action can have one of the following values:

  • Add — a local item in the project does not exist in the target org and will be created; marked in a green color;
  • Overwrite — a target organization contains an element with the same name, and it will be overwritten with your local version; marked in an orange color;
  • Delete — a local project does not include an item which is present in the target organization and the later one will be deleted on deployment; marked in a red color;
  • No Action — an item which can not be modified by The Welkin Suite's deployment (for example, a standard object can't be removed, etc.); marked in a gray color.

To find a necessary item in this list, you can use a search field above the table. Clicking on the column's header sorts the list in ascending or descending alphabetical order. In addition, when you select a row in the table, you will see a hint about the action under the table.

You are also able to Select all items in the table by marking the corresponding checkbox above the table.

In case you need more precise information on the differences between your project and destination Salesforce organization you can switch to the Deep comparison mode by clicking on the corresponding button.

Deep comparison

In this mode, The Welkin Suite additionally compares metadata content and provides you more details. Comparing in this way requires a significantly greater amount of time because the IDE will have to download all metadata from the organization, however, it mostly depends on the size of your organization. To see the difference between files' content in your TWS project and on a target organization., click on the Show difference button in the first column for applicable files.

Show difference

The IDE will show you a comparison in the same wizard, just below the list of components for deployment.

Deep comparison mode

The deep content comparison introduces one more value in the Action column — No Differences. It means that both local and target items are identical. Such elements also are marked in gray color and are ordered right below the Delete items in the table.

No Differences

Check all the items that you want to deploy to the target org and click on the Next button to move to the next step.

Additional deployment settings

On the next step of the process, you are able to set the following deployment options:

  • Validate only — your changes won't be deployed to the target organization but only validated against it. Checking this option disables Rollback on error and Purge on delete ones,
  • Ignore warnings — warnings do not fail deployment and otherwise, warnings would be treated as errors and would fail deployment,
  • Rollback on error — indicates whether any failure causes a deployment rollback. It is always checked for deployment to production organizations,
  • Purge on delete — deleted components won't be stored in the Salesforce's Recycle Bin,
  • Apply destructive changes at the end of the deployment process — the destructive changes would be performed at the end of the deployment, otherwise, they would be executed before all other parts of the deployment,
  • Test level — it specifies which tests are run as part of the deployment process.

Deployment settings

Deployment test level

In the Test level configuration you are able to select one of the following options:

  • No test run — no tests are run. This test level applies only to deployments to development environments, such as Sandbox, Developer Edition, or trial organizations.
  • Run specified tests — only the tests that you select during the next step are executed. Code Coverage requirements differ from the default coverage requirements when using this test level. Each class and trigger in the deployment package must be covered by the executed tests for a minimum of 75 % code coverage. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.
  • Run local tests — all tests in your org are run, except the ones that originate from installed managed packages.
  • Run all tests in organization — all tests are run. The tests include all tests in your org, including tests of managed packages.
NB: When you are deploying to a Production Organization, the option No test run can't be available.

If you select Run specified tests, after pressing the Next button, you will have an option to select unit tests to execute. Overwise, this step is skipped in the deployment process.

Selecting unit tests is represented as a table with the following columns:

  • Availability — specifies where this unit test originates from; it can have one of the following values:
    • Local — the given unit test is not currently present in the target organization and will be deployed as a part of the deployment process,
    • Remote — the given unit test is present in the target organization and won't be changed in the current deployment,
    • Both — the given unit test currently exists in the target organization, however, it will be overwritten with the current deployment, this means that the new version of the unit test will be executed,
  • Name — the API Name of the apex class with unit tests.

Deployment tests

Once you select needed unit tests to be executed, you can proceed to the deployment itself and results.

Deployment progress and results

Deployment status is shown as 2 separate progress bars: for components deployment itself and for unit tests execution. Your organization is polled each 10 seconds for status updates, and you will see all updates on this screen. Also if there are any error during the deployment or tests execution, the corresponding progress bar will change it's color to red.

Deployment status failed

If during the deployment you decide to cancel it, you can always do this with the Cancel Deployment button. The Welkin Suite will send a request to Salesforce to cancel the deployment and rollback all the changes.

In case if there are any deployment errors, you will see detailed results report with the following tabs available:

  • Deployment results — all issues with the deployment itself including failures due to missing dependencies or any other reasons,
  • Deployment test results — all unit tests results, both succeeded and failed. They will be shown if at least one apex unit test will be executed. For failed test methods, in addition to the general information like class and method name, you will also get the stacktrace and the message about the failure,
  • Deployment code coverage — information about any code coverage-related deployment issues. It will be shown if there is at least one such error.

Deployment errors

In each of the tabs you have 2 options to save the results:

  • click on the Export to CSV button to save the currently opened table as a .csv file,
  • from a context menu for any row in the results table select the Copy option, and the formatted information from that row will be placed in the clipboard.

When the deployment process is finished successfully, you'll get the appropriate message.

Deployment has finished successfully

Click on the Finish button to close the wizard.

In this section:

This also may be useful:

Last modified: 2018/01/31 10:15

footer image