Force.com Migration Tool - How to correctly retrieve & deploy
I'm looking for some guidance on how this tool is widely used.
We have the following scenario:
Source: 1x Production org, with 1 (or more) managed packages installed. Targets: Multiple Production orgs, with 1 (or more) managed packages installed.
We are an ISV, and our managed package will be installed in each of the Production orgs mentioned above.
Our challenge is trying to retrieve metadata data from the source org. and deploy to multiple targets orgs.
Here are the main issue we have come up against thus far:
Managed components are retrieved when retrieving metadata from the source org. This means we cannot deploy the metadata until we manually manipulate the metadata files, removing any managed content. This is incredibly time consuming. The only solution we have found thus far is to manually compile unpackaged/package.xml, explicitly including only those unmanaged custom components which we want to retrieve. This is also very time consuming.
So far, I've dabbled in Ant replaceregexp scripts to remove the managed components from the metadata files, but have been unsuccessful.
For example:
Has anyone come across this issue before and if so, how did you deal with it?
If anyone has any Ant scripts that they have written to get around common cross-organisation deployment issues that they don't mind sharing it would be greatly appreciated.
Thanks!
One possible solution is to use Packages as a container for your code. This allows you to retrieve only the code in your package from an org which ignores all other metadata in the org such as managed package fields, standard Salesforce fields, and any customer created fields.
To test it out, go to Setup->Create->Packages in your source org. Create an unmanaged package and use the Add Components button to add all the metadata you want to bundle in your package. Then, retrieve all metadata from the package into a folder. You'll wind up with a folder containing all the metadata and a package.xml file formatted to allow deployment into a Package in your target orgs.
The key difference in the package.xml is the inclusion of the element which flips on the deploy to package functionality.
The one catch is the target org will need to have a package with the same name already created before the deployment but this is a one time manual step per target org.
There are, however, some drawbacks. Some metadata types won't deploy this way. For example, ActionOverrides don't work this way as they can't be bundled in a package. As a workaround, you can create a normal bundle of metadata for use only in deploying the types you can't deploy as part of a package.