Build Project

The Build functionality helps you to move your changes to an org directly from the IDE. It's available for the standard project metadata components (exept objects):

If you work with other types of metadata and need to move the changes in them to an org, use the functionality of deploying.

Build options

The Welkin Suite offers you multiple ways to execute the build, depending on your purpose, and volume of changes that you want to implement. You can find all the available options for the build in the context menu of a solution / project in the Solution Explorer, and in the Main Menu ⇒ Build.


Build from the Main Menu


  • Build Solution — to move all the changes from the entire solution to an org(s),
  • Build Selection (the F5 hotkey) — to build changes only from a selected project,
  • Build and Run Tests (the Ctrl+F5 hotkey) — to run all the tests right after a build is finished.

In addition, you can access to the build options via the Build toolbar.

Build process

Once you start a build process, the Output panel is displayed automatically reflecting all the changes of the build status. You are able to see an icon in the bottom right corner of the IDE window and the build status in the status bar. All the steps of the building process are described below one by one.


Building process


Step 1. Detecting changes locally

At the first step, TWS detects all the changes in the files locally. You can revise the complete list of such files that are going to be built in the Pending changes panel. In addition to these files, The Welkin Suite also gathers and sends on Salesforce all the dependent files that may relate to the changes.

If there are no changes, the build won't send any file to the Salesforce org.


No changes to build


Step 2. Detecting changes on Salesforce

At the second stage, The Welkin Suite checks the Salesforce org if files that were changed locally were not changed in the org.

If such changes are detected, you will see a list of files in the Error List Panel with the message that you need to pull these files first to get the updated version.

If there are no changes on Salesforce, your files will be sent to the build.

Step 3. Updating local files

If during the build process TWS detects errors, they will be displayed in the Error List Panel and the build status will be Failed.


Build failed


If no errors are returned, TWS redownloads the built files from SF if the data from their *-meta.xml files were changed.

After all these actions TWS calculates hash for downloaded files and store them in order to check for changes in SF on the next build.

When the build has finished successfully, you will see the following status in the Output Panel.


Build succeeded


Cancel the current Build

If for some reason the build is taking too long, or it's stuck, or you've changed your mind and don't want to build the changes, you can cancel it by clicking on the Cancel option in the Build menu or pressing the Ctrl+Break hotkey.


Cancel the current Build


NB: The cancellation of the build depends on the current step of the process:
1. if the process is going locally (step 1), it will be successfully canceled,
2. if the build has already sent a request to Salesforce and queue that includes the building files, this request can be in queue also, so the cancellation may take some time,
3. if the build is completed on Salesforce, it won't be canceled in TWS.

In this section:

This also may be useful:

Last modified: 2017/02/02 11:51

footer image