Automatically detecting problems in your Salesforce Change Sets and deployment packages
Stephen Chambers on April 4th 2016
Have you ever experienced a failed deployment to one of your Salesforce orgs?
Perhaps you've even experienced a deployment failure despite extensive preparation. All tests have passed and the validated deployment package is just waiting to go, and it's only after the process kicks off that it implodes and the deployment has to be rolled back while you pick apart the reasons.
It's a story we hear regularly. The deployment process decides not to play ball and you're faced with a potentially lengthy investigation to identify the cause of the failure, before testing the fixes and trying again. When there's a small release window in which to successfully deploy changes, delays become even more significant.
This scenario is one we're looking to fix by identifying issues before you even get to the deployment validation stage.
The pre-deployment problem analyzer from Gearset
We've implemented a pre-deployment problem analyzer feature that examines the objects due for deployment to your target org and identifies issues that would almost certainly wreck your best laid plans.
If you're in the mood, we can even automatically fix most of them for you. We're nice like that.
You don't even have to do anything to trigger the analysis taking place. The analyzer simply gets to work checking against known causes of deployment failures, and it won't get in the way if everything looks good.
What does the problem analyzer detect?
Based on issues that surface for our users, our problem analyzer can now warn you about and fix problems such as:
- Missing dependencies: items that need to be created or added to the deployment in order for it to work.
- Missing deletions: some items are dependent on something that's being deleted. These items need to be deleted as well in order for the deployment to work.
- Compatibility problems: some items may be incompatible with the target due to differences or changes in the API versions.
- History tracking settings: if a field has history tracking enabled, but the parent object in the target organization doesn't, the field will need to be removed from the deployment or it will likely fail.
- Items using features that might not be enabled in the target org: if some standard object fields are being deployed, but they don't exist in the target organization, this indicates they might use features that aren't enabled in the target org and you might need to remove them to avoid the deployment failing.
- Object fields named differently in the source and target due to API version differences: if a field exists in both the source and target but is named differently in each due to the difference in API version, then, once again, the deployment will most likely fail.
- Critical deployment issues: issues whereby an issue will almost certainly cause a deployment to fail that should be resolved before the planned deployment can proceed. We're unable to automatically fix these problems, but can warn you prior to the deployment package validation stage taking place.
SummaryIf you recognize any of the above from your own experiences of deployments gone wrong, we can now tell you in advance that they exist and help you resolve them - before it's too late.
We're adding more checks to the problem analyzer as they surface so that we can deal with new scenarios and save people from major deployment headaches.
If you'd like to see if it helps with your deployments, simply click below and try it out for free for 30 days.