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:

<target name="removeManagedFields">
    <replaceregexp  flags="gis" 
                    match="&lt;fields&gt;^(?!&lt;fields&gt;$).*&lt;fullName&gt;prefix__^(?!&lt;fields&gt;$).*&lt;/fields&gt;"
                    byline="false"
        >
        <substitution expression=""/>
        <fileset dir="${sf.retrieveFolder}">
            <include name="**/*.object"/>
        </fileset>
    </replaceregexp>
</target>

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!

Attribution to: Davin Casey

Possible Suggestion/Solution #1

In response to the comments on the question...

Below is an extract from a package.xml where we have one of our managed packages (namespace cve) deployed and then add custom fields and objects (and code and other components) in unmanaged (no namespace) form. The only CustomObject references we make are to entirely new objects. Any fields we add (or modify such as changing picklist contents) are referenced using CustomField. That does result in a .object file but it only contains the nominated fields. (Note this does not allow an occasional object-level setting to be preserved and manual steps are needed for those.)

But I'm probably still not following you as I don't understand your problem 1: if the managed package is installed in both the source and destination orgs why does the presence of managed package fields cause errors when you deploy to the destination org?

<types>
    <members>APXTConga4__Conga_Template__c.DataLoaderName__c</members>
    <members>APXT_CMQR__Conga_Merge_Query__c.DataLoaderName__c</members>
    <members>Account.Effective__c</members>
    <members>Account.Expiration__c</members>
    <members>Contact.FullTime__c</members>
    <members>Contact.HoursWorkedPerWeek__c</members>
    <members>Contact.JobDescriptionDate__c</members>
    <members>Contact.JobDescription__c</members>
    <members>Task.Subject</members>
    <members>cve__Adjustment__c.cve__Status__c</members>
    <members>cve__Adjustment__c.Type__c</members>
    <members>cve__BenefitClaimed__c.DefinitionOfDisabilityChangeCalendar__c</members> 
    <members>cve__PaymentSpecification__c.cve__ExpenseType__c</members>
    <members>cve__Payment__c.First__c</members>              
    <members>cve__Policy__c.Situs__c</members>
    <members>cve__Product__c.cve__LineOfBusiness__c</members>
    <name>CustomField</name>
</types>
<types>
    <members>BenefitClaimedAuthorityLevels__c</members>
    <members>KeyRelationship__c</members>
    <name>CustomObject</name>
</types>

Attribution to: Keith C

Possible Suggestion/Solution #2

One more possible solution is by following the below steps :

1> Use sf:listMetadata task of Force.com migration tool to retrieve
the information of all items(including managed package) of any
specific metadata type.

2> Use a script, may be a generic java program to filter out the
required items from the list above. We will get the names of final
list of components of any metadata type using this step.

3> Now finally using the final list in package.xml and use
sf:retrieve task of Force.com migration tool.

Using this approach you can retrieve the metadata components without much manual intervention from your Salesforce org and that too in no time.

You can check out the below link for more details: Retrieve list of components of any metadata type from a managed package

For your use case , in the generic properties.file , you can simply change the setting includePackage from true to false. And your are done.

Thanks.

Attribution to: Subhojeet_Sfdc

Possible Suggestion/Solution #3

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.

I just wrote up the build.xml targets in a different answer you can reference here: https://salesforce.stackexchange.com/a/31437/4832

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.

Attribution to: Jason Lantz

Possible Suggestion/Solution #4

Only one managed package will be available in developer edition .Managed packages will not be supported in other editions . name space prefix will not be available in other editions.So this might be cause of the problem. We can deploy managed packages between dev orgs only.

Regards,

Naveen

SSE

http://www.autorabit.com"

Attribution to: naveen
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/30092