We currently use changesets to deploy to production for apex classes and configuration items. It is taking a long time for deployment because the validation on the production org takes a longer time to accomplish this. I know i can easily do a validation using ant to cut down the validation time but unfortunately the end user team does not allow this.Is there anything we can do to cut down the time taken to do the validate task for changesets in the production org?
Buyan
[SalesForce] deployment taking longer time using changesets
Related Solutions
When you run in the sandbox are you running the tests in parallel? When you deploy to production the tests are not run in parallel, so it will likely take longer to run all of them. If you are running in parallel in the sandbox, you can switch to not run in parallel to get a better idea of how long the actual deployment will take.
If you are running in parallel in the sandbox it could be that there is some contention occurring for a shared resource. Also, Apex tests are placed in the Apex Job Queue for execution according to the documentation, so there could be some delay there, although 6 minutes+ seems excessive.
There could be different causes for the fluctuations in overall time between entire test runs. The documentation on Salesforce Asynchronous Processing has more info on how asynchronous processing is handled. It could be that there are a differing number of other orgs running at the same time (less when it takes less time...more when it takes longer). It could be that some tests depend on some shared resource and during certain test runs they happen to execute at the same time and in other test executions they run at separate times and don't have an issue.
I would rather have longer deploys and more unit tests that cover as many use cases as possible. I would not recommend that you remove valid tests (e.g., negative tests, edge cases, etc.) to reduce running time even if doing so saves time and doesn't reduce coverage. The 30 minutes you save on your scheduled deployments will easily be eaten up by time lost due to regressions introduced that would've been caught by the removed tests.
For what it's worth, I've deployed to an org that has roughly ~1000 test cases (methods) and a relatively complex data model and it takes close to 45 minutes for production deployments.
One approach that you can take to save some time is to run the validate only deploy the night before the deploy (assuming you deploy in the early morning -- adjust this example as necessary) and then on the following morning of the deploy run the deploy without the validate step. Salesforce will still do the validate and the deployment will fail if it doesn't validate, so you don't have anything to worry about. If you are currently doing the 1.5 hr validate deploy followed by a 1.5 hr actual deploy this will save you 1.5 hrs on the day of your actual deployment.
Lastly, if you are completely stuck you could start violating some testing best practices:
- Unbulkify tests. Always create the minimal amount of records for a test.
- Remove methods that don't add additional coverage.
- Use existing records in the database.
If you do any of them it would be a good idea to structure the test code in a way that you could "toggle" that functionality. E.g., have a setting that holds the number of records to create for bulk testing and in preparation test it with the high number and on the actual deploy set it to 1, use a custom setting to conditionally execute tests that don't add coverage and don't execute them on deploy, etc.
The error log shows a number of errors in the metadata you're trying to deploy through the Metadata API which the Force.com Ant Migration Tool ultimately calls. My hunch is that a full save to server from Force IDE would get the same errors.
One thing I've noticed about deployment logs is that you can often ignore the massive number of duplicate lines. For example, the following error appears all over your log:
Error: Required field is missing: type
It's likely that a previous failure is causing this error and fixing the other failures will make this one go away. So, going with that strategy, there are a few errors you need to fix in the metadata files to get the deployment to pass:
[sf:deploy] 1. settings/Account.settings -- Error: You cannot disable account teams using the Metadata API. Your system administrator can disable account teams from the Account Team Setup page.
Account Teams are not supported for deployment through the Metadata API: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_unsupported_types.htm
[sf:deploy] 2. objects/AccountContactRole.object -- Error: ControlledByParent is not a valid sharing model for AccountContactRole
Adjust the sharing model of AccountContactRole.object or if you didn't make any customizations to it, delete the file locally so it's not a part of your deployment.
[sf:deploy] 3. objects/Site.object -- Error: Entity cannot be untracked.
This is likely due to the same issue with the same fix as discussed here: https://developer.salesforce.com/forums/ForumsMain?id=906F00000008k09IAA
[sf:deploy] 163. objects/Contract.object (Contract.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4. Only components in the same namespace as the organization can be created through the API (line 235, column 15)
...
[sf:deploy] 171. objects/Solution.object (Solution.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4. Only components in the same namespace as the organization can be created through the API (line 120, column 15)
These errors indicate that you're trying to deploy metadata which comes from the APXTConga4 package. You can only deploy managed page components by installing the managed package. There is a trick you can do via the migration tool to install managed packages into the org as a separate deployment but covering that is beyond this question.
Edit the offending objects and remove any metadata starting with APXTConga4__
Finally, I wanted to point to another option I've been working with lately. You can create an unmanaged package in your sandbox org (Setup -> Create -> Packages) and then add all the custom code you want to migrate to it. Then you can use Ant to pull down only the metadata you chose to include in that package. This approach helps you avoid a lot of the issues you're seeing as it doesn't pull down anything from standard salesforce or installed packages, only the code you explicitly tell it to include. I plan to write a blog post on this approach soon, but you can get some more details from this answer I posted a few months back:
Using sf:bulkRetrieve do not fetch metadata components associated with a managed package
Best Answer
Changeset deployment usually does not have SLA and what you have experienced is an expected behavior. Deployment time will always vary and how long one deployment takes to complete does not become a benchmark on how long it'll take to complete another
There are times when changeset deployment will hit a legitimate issue such as gack or a lock and when those occur, Salesforce support can definitely investigate and escalate to have the issue rectified. However in few cases the deployment doesn't hit any gack or lock.
If it took this long to complete may possibly be link to the the many post release patches Salesforce.com have been rolling out, as when a patch goes out active requests like changesets are temporary put on hold and resumed when ready, other possible causes of extended deployment time are size/types of component being deploy and how it affect/changes the org, heavy traffic on the instance or simply multiple deployment / validation holding up the total overall deployment process in the org.
However we need to remember there are no SLA with changeset, but if you want to deploy quicker and have more control over their deployment, then IDE / ANT is the way to go.