How to Deploy a Release Package in Salesforce

Standard

With each new feature release, bug squashing, and spring cleaning of your code base there is the inevitable deployment process which can be daunting at first and frustrating if not structured well. Develop and deploy faster! After many deployments I’ve setup a process streamlines this task within development.

Setup a Release Package

deploy releasesIn your local Salesforce environment create a folder called “Releases“. Inside of that folder create another folder and name it after your release. For this example we’ll call it 1.0.3

This is where you will setup your release package and eventually ZIP it into a deploy-able package.

Inside your release folder you will need to place any Salesforce component folders that are part of your package. For example, if you are deploying a trigger and some classes then you will need a triggers & classes folder, along with the .trigger and .cls files that are being deployed inside of them each respectively.

 

Create a Package.xml

Once all the files/folders are in your package as needed, all that’s left is to create a package.xml that declares which files you are deploying. The developer of the HaoIDE Sublime Text plugin has a short video showing this process. Otherwise just copy a package.xml from your Production project and modify it appropriately so that it only contains the elements that you intend to be deployed in the package. Here is a simple example:

package-example

Zip Your Release Package

release-exampleOnce the package is complete you should have something that looks like this. Then you will need to select the contents and zip them (make sure this includes your package.xml). Once you have a ZIP, drag and drop to open it in Sublime Text (optional step but easier than alternative), once in Sublime Text right click in order to get the context menu and select “Copy File Path“.

Deploy Your Release Package

Now all that’s left is to deploy the ZIP package. From Sublime Text, click HaoIDE > Metadata > Deploy Package.zip and in the input field paste the path to the zip file that you copied just previously.

Here’s a sample video

Destructive Changes

If you need to do destructive changes then you will need to also create a destructiveChanges.xml (version 32.0 and prior), or destructiveChangesPost.xml and/or destructiveChangesPre.xml for package version 33.0; the latter of the two is the easiest (Post means to destructive AFTER deploying changes and Pre is used for destructive changes BEFORE deploying the package).

Here is an example of what this file would look like:

destructiveChangesPost-xml-example

 

As you can see the structure is the same as when building a package.xml, the only difference is this file is declaring what will be destructed and when (based on Post/Pre appending).

NOTE: If you only need to destruct changes and are not deploying anything, then at the bare minimum you need your destruct XML and a package XML that includes the version number

 

Conclusion

Hope that helps, there’s not much to it. Essentially whenever you are deploying to any environment, if you are using the context options within HoaIDE or MavensMate, etc., they are essentially doing this process for you. When releasing portions of code its more effective to package releases together so that you there are no dependency issues during the attempt that would cause it to fail. Good luck!

For more information when using HaoIDE be sure to see the deployment documentation

Leave a Reply

Your email address will not be published. Required fields are marked *