Improved Salesforce changes deployment to another Org in Spire R12

The first spring release of The Welkin Suite Spire is marked by the blossom of one of its earliest features - the deployment functionality. In the new version, we have overlooked the fundamentals, and this we are glad to present the new and improved Salesforce changes deployment to another organization. This renovation introduces the fresh new approach to the deployment process, which has become more adaptive to your personal requirements, as well as a lot more straightforward and smooth. 

Advanced Salesforce changes deployment to another Organization

The Welkin Suite for Windows has provided you with an ability to deploy files to another organization almost from the very beginning.  This time, our developers have done a great job to improve this process, add the new settings, give you an ability to run separate tests, or don't run them at all, etc. In other words, they have changed entire deployment process to make it really beneficial for your working process. In The Welkin Suite Spire R12, you will find the new possibilities for Salesforce changes deployment to another organization from the IDE.

As usual, you can start the deployment process by launching the 'Deploy to organization' wizard from the menu Project -> Deploy to organization. First, you need to select the environment type of your target organization, and specify its credentials - login, password, and security token, if the latter is needed. And here is where the fun part begins 

Set your deployment plan

Now you can start configuring your deployment by selecting the necessary files, which should be added, deleted, or overwritten on your target Organization. This is really easy and convenient, since all the files from both orgs are present in one list, and they are compared in a frame of their presence in the organizations.

This is the high-level comparison, so you will see if the file with the same name exists in your TWS project, or on a target-destination Organization. Also, this comparison will show you the action, which can be applied to each of the files during the deployment process, so they are as follows:

• Add - the local item from your TWS project does not exist in the target org, and will be created there
• Overwrite - the target organization contains an element with the same name, and it will be overwritten with your local version
• Delete - the local project does not include an item that is present in the target organization, and this item will be deleted on deployment
• No Action - the item that cannot be modified by The Welkin Suite's deployment (for example - standard object can't be removed, etc.)

We would like to draw your attention to the fact that, when you select any of the files, the enhanced description for a possible action will appear under the table to clarify the results of the action.

In the list of files, after the possible action, you will see the metadata type of a file, and its name. 

Using the checkboxes, please select the necessary files for the deployment. For easier navigation, all files are sorted by action, and they are highlighted according to the action; in terms of one action, they are displayed by the metadata types. In addition, you can use the 'Search' field to find the necessary files within a second. And more, you can use the filters for the 'Action' and 'Type' columns to select the files related solely to the needed action(s) in the list, or switch to one or several metadata types.

Also, you can get a more detailed comparison for the content of your TWS project and a target Organization, if this is needed. We have implemented the 'Deep comparison' option for this, and it allows you to compare the content of the files, in addition to their presence. As a result, you will not only see if a file exists or can be deleted from the Organization, but if the file with the same name is identical, or its content is somewhat different. In the case of using the 'Deep comparison' option, you will get one more possible type of actions - 'NoDifferences', which, obviously, means that both local and target items are identical. Such elements would be displayed in the same color as 'No Action' ones, and they will be located in the list of all the files, right below the 'Delete' items in the table.

This type of comparison will require a considerably larger amount of time because the IDE will need to download all the metadata from the organization. However, it mostly depends on the size of your organization.

Adjust deployment options

When you have selected the necessary files for your deployment to another organization, you can choose which options should be applied for the process itself, and here are the cases:

• Validate only: selecting this option will allow you to validate your changes on a target Organization without deploying them; since no changes will be saved, the additional options 'Rollback on error' and 'Purge on delete' become disabled for the current deployment.
• Ignore warnings: each deployment process can include some warnings, and in case the checkbox for the option is active, these warnings won't be considered as a reason for failures of the process; otherwise, they will be treated as errors, and would cause deployment failure.
• Rollback on error: the name of the option implies the further action - if there are any reasons for the failed deployment - all the changes will be canceled on your target Organization; the option is always checked if you are going to deploy to Production Organization.
• Purge on delete: if you are going to delete some files on your target Organization and enable this option, these files would be removed even from the Salesforce's Recycle Bin on the remote.
• Apply destructive changes at the end of the deployment process: when you enable this option, the destructive changes will be performed at the end of the deployment. Otherwise, they will be executed before the other parts of the deployment.

We would like to highlight the next option separately, since it is one of the most crucial deployment options that was missing in our previous version of the deployment process. It is the selection of deployment test level. Now you have an ability to specify which tests will bu run in a frame of your deploying, and whether they should be run at all. Here you can find the description for each of the options (the descriptions are provided according to Salesforce documentation):

• 'No test run' - No tests are run. This test level applies only to the 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.

The further steps for specifying the test level settings are available for you at the next stage.

Select tests to run

You won't face this stage, unless you selected 'Run specified tests' test level at the previous deployment step. If you've done so, you will see a full list of unit tests available on the target Organization, as well as the unit tests included into your deployment on the first steps.

The provided approach should already be familiar to you - a list of unit test classes, with an 'Availability' parameters, which can have one of the following values:

• Local - the given unit test is not available in the target organization, and is selected to be deployed to it
• Remote - the given unit test is present in the target organization, and no local version of the same unit test is included into the deployment, so it won't be changed there
• Both - the given unit test is available in the target organization, and at the same time, its another version will be deployed, so in this case, the new version of the unit test will be executed

Once you're done with unit tests selection, you can proceed to the deployment itself by pressing the 'Next' button.

Track the deployment process and get results

When the deployment starts, The Welkin Suite will poll your target Organization every 10 seconds to provide you with the actual status of the process. However, you won't be able to spot the so-famous #deploymentfish in TWS because we're using 2 regular progress bars - one for deployment, and the second for unit tests results. In case something fails during the deployment stage, the progress bar will turn red, and you will notice it immediately. And, of course, you always have an option to cancel the deployment if you decide so.

The perfect scenario for every Salesforce Developer suggests that your deployment will pass on the first attempt, however it's no big deal if it doesn't - you will see very detailed results for the deployment, so you will be able to adjust the deployment options or components.

Depending on the reasons behind the failure, you will see one or several of the following informational tabs:

• 'Deployment results' - all issues related to the deployment itself, including the failures triggered by the missing dependencies, or any other reasons
• 'Deployment test results' - all unit tests results, both succeeded and failed. Will be shown if at least one Apex unit test is executed. In addition to the general information for the failed test methods, such as class and method name, you will also get the stacktrace, and the failure message.
• 'Deployment code coverage' - the information about any code coverage-related deployment issue. Will be shown if at least one such error is present.

Each of these tabs provides you with 2 different ways to save or copy the results:

• You can click on the 'Save Results to CSV file' button to save a report
• Or you can right-click on any row in the list and select the 'Copy' command to copy this row to the clipboard

Usually, there are lots of different reasons behind the failure of your deployment, but one of the most common cases, based on our experience, is related to the missing or extra components. You can forget to add some important class to the deployment plan for some reason, or you can accidentally include an unused trigger without unit tests for it. Such an insignificant reason should not lead to your starting the entire process over again, so you can always use the 'Back' button to return to the previous steps, and quickly resolve the issues.

Other Changes

Also, we have made additional changes in the the different areas of TWS functionality. For example, the performance for the project creation process was improved. We have reached it by moving the saving of local history details to the separate thread, which now will be run in a background instead of being a part of the project creation itself. 

In addition, our developers have made some changes in terms of filtering a Salesforce log file. Now you can see the filtered entries in the hierarchical view, and the collapsed blocks include all the intermediate lines between the selected for displaying.

When you are working with FLS tab in the sObject Inspector, you can now track the changed fields easier using the marker, which is applied after any of the settings were modified:

We have implemented one more update related to the FLS tab, which concerns the filtering options. There was the issue when displaying of the selected items could be incorrect after using the 'Select All' or 'Select None' options.

The UI changes were applied to all TWS wizards to refresh their view and make your working process in the IDE more pleasing to the eye.

The issue related to the case when not all the files were updated or added to your TWS project during the pull from Salesforce is now fixed. This was caused by the timeout, which was set for each metadata type separately. Some of the metadata can include more files than the other, and not all the files were downloaded in the limited time. Now you will get all the necessary files.

All the other fixes can be found in the Full list of changes.

As we are getting ready for the Big Spring Release on May 22, we are on the track to implementing some of the improvements in advance - as we have mentioned in the announcement. Hence, our new releases will introduce even more features to freshen up your development process! And don't forget - you can always impact the priority of our updates, so if you have any suggestions as to what you'd like to see in The Welkin Suite first, please don't hesitate to tell us! 

Full list of changes

Features

• Implemented the advanced 'Salesforce changes deployment to another organization' functionality

Improvements

• Added the changes marker in FLS tab to track changed fields
• Improved the filtering for log files with block collapsing and displaying the hierarchical view
• Improved the performance for the project creation process
• Changed UI for TWS wizards

Fixes

• Fixed the issue when not all files were updated/downloaded during the pull process
• Fixed the incorrect filtering in the 'Bulk Apply' window on the FLS tab after using the 'Select All' or 'Select None' options
• Fixed the issue when results from SOQL editor were copied with a redundant new line
• Fixed the rare cases of the errors during the project creation
• Fixed the issue when there was no ability to download a specific type of dashboards to Wave project
• Fixed the incorrect link in one of TWS tips