Using Salesforce quick deploy and validated deployment packages with Gearset
Jason Mann on March 14th 2016
Validation-only deployments catch errors early, support an Agile release approach, and can significantly shorten the final Production deployment. With our latest update, Gearset now fully supports validation-only deployments.
Validating saves time
With large or complex Salesforce orgs, running unit tests and deploying changes can take hours. If anything goes wrong, it can be a slow process to fix the errors and rebuild the package. Validating your packages pre-deployment not only saves time but also spots errors early.
If you use Change Sets you’ll be familiar with the process of creating a validated Change Set, in which you get to test the success or failure of your changes before making the deployment. You may also be able to avoid re-running your unit tests by using the quick deployment feature currently in pilot. Validation is a great way to manage the release process and take some of the risk out of real deployments.
Full support for validated packages in Gearset
Back in November, we released initial support for creating validated packages in Gearset. These are our equivalent of a validated Change Set, allowing you to test your package without deploying, and pre-run your unit tests.
We've refined the workflow over the past few months, and you can now take advantage of the benefits of validated packages from the new Validation history tab in Gearset.
Creating a validated package in Gearset
Let’s run through an example of how to create and deploy a validated package with Gearset.
1. Run a comparison between two orgs, and select the objects you want to include in your deployment package
2. Click Validate deployment to begin the validation process. Once your validation succeeds, you’ll get a summary report and a link to your validation history
3. The Validation history page stores a list of all of your successfully validated but undeployed packages. Select the package you want, and click Deploy validated package
4. If your package has not expired, Gearset will try to utilise quick deploy to avoid re-running your unit tests. Once the deployment succeeds, you’ll get the usual deployment report saved to your deployment history
Top tip: if you’re moving a package through orgs as part of a deployment pipeline, select Clone package (find out more about cloning packages) to automatically clone your inbound package. Chose a new source and target org, and Gearset will run a comparison and select the same object types for deployment.
What happens if I deploy a package that has expired?
Salesforce enforces a 96 hour limit on the validity of unit tests. If you deploy a package outside of this window, your unit tests will re-run as if you were running a full deployment.
The longer you leave your package without deploying, the greater the chances of changes being made in your org which could cause the deployment to fail. We encourage you to deploy validated packages that have not yet expired to minimise these risks.