2

We have a big project depending on Metadata API and we are using deploying of all components at once.

But now size of components have become too large (80MB) and our server can't send files with this size. If we send files by dividing zip into 20 MB chunks then deployment get failed due to component dependencies.

Is there any way Metadata API like Tooling API where we can create Metadata container on Salesforce side and when we have enough required components then we process the deployment.

The major issue we are facing is dependencies of components if we deploy by multiple zip files. File A can have dependencies with File B and vice-versa. We are doing file based deployment.

Any help will be appreciated.

  • Apparently there's no good solution to this. Much of the salesforce data model has circular dependencies, which, practically speaking, prevents you from splitting your deployment into smaller ones. – Jeremy Ross Mar 25 '15 at 3:18
  • how did you fixed/handled this eventually? – OK999 Aug 23 '17 at 15:41
3

You may be able to get some progress by considering at a more general component level what dependencies exist and breaking it up by component type. For example try deploying selectively in this order from the applicable /src subfolders and within those see if you can filter further, e.g. test classes.

  1. All Custom Objects and layouts
  2. All Custom Labels (if you have any)
  3. All Apex classes (without tests)
  4. All Apex test classes
  5. All Apex triggers
  6. All Visualforce pages

This approach makes use of the fact that you Setup related information cannot directly reference Apex code, so you can try to deploy as much of that ahead of the code. Then leverage knowledge that Apex code does not reference private Apex test methods, so these can be later deployed. You may also have further outer dependencies in your code base you can identify generally. Once this is all done, issue a runAll tests request.

NOTE: The above assumes your not deploying to production, if so you will have to combine the Apex classes and tests together.

  • Thank you very much for the response! Actually, we only deploying to production environments and the major issue we face is the interdependency of components. We have designed that scenario of deploying components by order of their dependency but our deployment includes all components from Sales, Service, Marketing, Programatic, Communities etc. Does Metadata API has method by which we can see dependencies between components or any method by which we could setup order deployment order dynamically? – Ashwani Aug 14 '14 at 15:25
  • I wish i could say yes, sadly it does not. So your getting an issue deploy just setup metadata? Have you considered using an unmanaged or even managed package perhaps? – Andrew Fawcett Aug 14 '14 at 16:10
  • We are deploying unmanaged components so we have scope of selecting components during deployment but we are not able to resolve their interdependency. We are dealing with all metadata components they are not limited to set up. Can we divide set up and programmatic components if it csn resolve dependencies? – Ashwani Aug 14 '14 at 16:35
  • Put are you using an "unmanaged package" you uploaded from your source org? help.salesforce.com/apex/… – Andrew Fawcett Aug 14 '14 at 16:36
  • 1
    ok, best of luck! – Andrew Fawcett Aug 15 '14 at 8:20
0

I think you could use unmanaged packages as containers to solve this. First, a distinction: I'm not referring to using unmanaged packages to distribute the code between orgs. What I mean is you can create multiple unmanaged packages in the source org, add metadata to them, and then retrieve from the packages via the metadata api.

The nice thing about packages is that they automatically include any metadata required by metadata you've included in the package. There are a few exceptions such as test classes which have to be manually selected.

To test it out, create an unmanaged package in the org (Setup -> Create -> Package) and add some metadata to it. Any metadata referenced by the metadata you include will be added to the package. You can create multiple packages and add metadata from different functions to them.

Then, retrieve from the metadata api with an ant call like:

<sf:retrieve 
  username="${sf.username}" 
  password="${sf.password}" 
  serverurl="${sf.serverurl}" 
  retrieveTarget="PackageNameHere" 
  packageNames="PackageNameHere"/>

You'll get all the metadata and dependencies in a directory with a package.xml file designed to deploy the code into an unmanaged package in another org. Then create the package in the target org manually (no api for this step) with the same name as from the source and then run a normal deploy from the retrieveTarget. It's not distributing via an unmanaged package, it's just using them as a container for metadata.

The way it deploys into the unmanaged package in the target org is by including the following line in the package.xml:

  <fullName>YourPackageHere</fullName>

In the target org, the unmanaged packages will contain all the metadata you deployed without needing to manually select it.

The other nice thing about this approach is that the retrieved metadata only includes whatever was in the package. This means if the package has 2 fields on Contact, your objects/Contact.object file will only have those two fields and nothing else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.