General operations in TWS

The main aim of any development process is to bring all the innovations to life. At a glance, the lifecycle of development on the platform consists of the following repeating steps:

  • pulling changes — downloading all the files of the project / solution that were changed outside the IDE,
  • editing — making changes,
  • building or deploying — implementing the changes into an org.

The processes of building and deploying are quite similar. The main difference is that the build functionality is available only for the standard project metadata components while the deployment — only for custom ones.

The Welkin Suite IDE uses an optimized approach to building / deploying projects in order to maximally reduce the time required for these operations. These processes consist of two main steps:

  1. сhange detection;
  2. building / deploying & error handling.

Change detection is a process that determines which files were changed locally and should be built on Salesforce. Unlike many other IDE’s, The Welkin Suite uses not only the file’s last modified timestamp but also the content hash to determine if there were any changes. Each time the files are saved, the hash value is recalculated and saved together with the last modified timestamp in special meta files in the Properties folder of a project.

While building / deploying the IDE checks, if a file was not modified outside of the environment, and if it was really changed by comparing it to the last pulled version from Salesforce. If there are no changes, the file won’t be sent to the org, so the operation time will be reduced.

You can detect the files that will be sent to the Salesforce org manually also, using the Pending Changes functionality.

For handling changes of Static Resources the detection process is the same with some additional steps and logic applied. Also, Static Resources are automatically packaged back into zip files if they were downloaded as zip files, preserving the initial archive structure no matter how the files are located in your project.

In cases where the files you are building / deploying were changed on the org since last time you have pulled, you won’t be allowed to proceed with build until you pull the latest changes from a server.

In this section:

  • How to Pull changes from Salesforce — this section describes the approaches to get the ultimate changes of your project's files from on org,
  • Building the Project — it describes the easiest way to move your changes into an org,
  • Deploy Objects — if you work with objects and non-code metadata types, this section will guide you through the process of implementing changes in such files to an org,
  • Deploy to Organization — move your changes to sandbox or even a production org, using these simple instructions.

This also may be useful:

Last modified: 2017/01/26 14:55

footer image