Deploy Faster with Summer ’15 Features

Buried in the pages of the Summer ’15 release notes is a little feature that you might easily pass by. If you take advantage of this feature, then you can drastically speed up your deployments to production. This new feature allows you to choose which tests are run in a deployment.

First of all, the biggest change is that tests are only run when you are deploying Apex classes or triggers. This means that your deployments will immediately be sped up if you are only deploying objects, new fields, workflow rules, etc. If you do have Apex in your deployment package, then by default all local tests are run. Local tests are those that are not namespaced (included in a managed package).

The cool thing is that you can now make a change to your build.xml file to specify tests to be run. When you do this, only the test you specify in the build.xml file are run and Salesforce only looks at the code coverage from those tests on the code you are deploying. As long as the tests pass and the code coverage is good, then your deployment will succeed.

What does this mean in a real life situation? I ran a couple of scenarios and saw marked improvements. If I deploy a single class the old fashioned way, then tests in my org take about 30 minutes to complete. If I instead specify a specific test class, then my deployment time dropped to 2 minutes. This is huge, when you think about needing to deploy an emergency patch. You no longer need to wait for all tests to complete.

A word of caution: if you have the luxury of time, I highly recommend you run all local tests and use the quick deploy feature. This allows you to stage your release and make sure everything is working properly. Use the specific tests option only in cases where you need to get something to production fast.

Upgrade your Migration Toolkit and start getting faster deployments! Let me know how you plan on using this new feature.

3 thoughts on “Deploy Faster with Summer ’15 Features”

  1. Not sure if it’s a bless or a curse.
    When you have automated processes you can easily affect them with workflows, validation and other non apex components.
    When we write test classes, we assert the full process works as expected using assertions.
    If new components will damage a process it can affect in 2 aspects: 1. Incorrect data in the system. 2. Future deployments of apex related components will fail.
    I think that this feature is problematic and i don’t think we will use it.
    I would like to hear your opinion on the issues i mentioned.

    1. I definitely agree with you, Gad. This is a feature you should use sparingly and knowing that you might be releasing something that breaks other code.

Leave a Reply