We had a previous rant at how lacking changesets are and that ant based deployments bring advantages.

One of the big drawbacks of changesets are that, although they can be cloned on the same org, there is no out the box way to reuse a changeset on a different org.

Having said that, changesets also have some useful features.

• A single changeset can be built by multiple developers.
• It can be reviewed by multiple users.
• It’s accessible in the org.
• No additional external tools needed.
• No network or proxy issues to sort.
• It is available and retained after deployment for audit purposes.

As Salesforce developers why can’t we use both methods interchangeably? Well, we can.

This post addresses how changesets and package.xml files can be generated from each other.

With a bit of work, you can do the following:

• Generate a package.xml from a changeset.
• Generate a changeset from a package.xml.
• Put those actions together to ‘export’ a changeset (as package.xml) and then use that to create a new matching changeset in another Salesforce org.

Changeset to Package.xml

This routine allows a package.xml file to be generated from an existing changeset.

• Package.xml is reusable and more flexible. It can be stored, modified and read easier.
• Review a changeset without the hassle of dealing with the pagination
• Save time when moving between multiple environments… Create changeset first and then use package.xml going forward. No need to manually repeat build the changeset in each org. Or use the package.xml to create new changesets on different orgs.
• When moving cross unconnected orgs, packages are the way to go. A changeset can be used to give a headstart to package generation.

Use ant retrieve command. Give credentials to the org with the changeset, and include the name of change set in the packageNames paramater.

<target name="retrieveChangeset"> 
  <mkdir="changesetfolder"> 
  <sf:retrieve 
     username="${sf.username}" 
     password="${sf.password}" 
     serverurl="${sf.serverurl}" 
     retrieveTarget="changesetfolder" 
     packageNames="changesetname" /> 
</target>

Package.xml to Changeset

We can again use ant to do the reverse. This could be useful for easier, automated, repeatable and quicker changeset creation.

Although ant can’t create a new changeset it can change the components in an existing changeset. So create an empty changeset first.

Set up your source data package.xml to have the <fullName> tag match the changeset name.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>MyChangeset</fullName>
 <types>
 <members>testController</members>
.....

Also change the name of the metadata folder to use the new changeset name.

Then use the ant deploy command to move your components into the waiting changeset.

<target name="populateChangeset">
 <sf:deploy 
 username="${sf.username}" 
 password="${sf.password}" 
 serverurl="${sf.serverurl}" 
 maxpoll ="${sf.maxPoll}"
 deployroot="MyChangeset"
 autoUpdatePackage="true"
 singlePackage="true"
 />
</target>

Best of both worlds? At least it gives us some options.