"drop" commands represent objects you want to remove from the destination instance.

The parameters represent the type of component being deployed, and the component itself, that you want to move to, or remove from, the target instance.

"start" and "commit" define the start and end of the objects to deploy

"package" downloads the components and assembles them into a zip file.

Now connect to the Salesforce instance that contains these components, and run the script. Upon completion you will have a zip file containing the items defined in the script.

Step 3: Deploy the deployment file

You can now connect the JDBC driver to the instance of Salesforce that you want to deploy the package to, and run the following command, pointing it at the "zip" file you defined when you originally created the package:

The zip file generated by the deployment tool can also be deployed using the Salesforce "ant" tool if you prefer.

If you need to "tweak" the code prior to deployment, you can edit the zip file using something like Total Commander, or unzip, edit, and rezip file, or you can explore the "patch" commands, as described in the next section.

Patching (Advanced Feature)

Salesforce development can sometimes force the use of hard-coded values, such as object ids, in places like Workflow. These object ids will need to be different in every environment you deploy to, and relying on humans to remember to manually change such values is tedious and unreliable. Stuntbyte's "patching" facility gives you a clean way to handle this issue.

Patch Definition

In the code below we define some "patch variables" that represent the values that are required in various deployment environments. eg: a "special user" id in dev, uat and prod. These names are completely arbitrary.

FAQ

How do I know what types of components can be deployed?

The types of components supported are defined here (except that these pages incorrectly state 'CustomLabels' is a component type -- actually it's singular, 'CustomLabel' -- yes, we have reported the problem, years ago).

You can also use your SQL tool to browse the "deployment" schema.

How do I know what names to use with the deployment?

These are generally the "developer name" used when the object was created, but the guaranteed way to figure it out is by accessing the "deployable" table that exists for each type. eg:

SELECT Identifier from deployable.CustomTab

NOTE: The "deployable" schema tables are internal to the JDBC driver and don't make use of the Salesforce query engine, consequently the only supported WHERE clause is "WHERE Identifier LIKE", and the LIKE expression isn't exhaustive :-)