How Blue Canvas can help you understand the deep dependencies and deployment issues that make change sets frustrating.
Let’s face it, deploying with Salesforce can be frustrating. You’re either using change sets or Ant scripts and both have their issues. Ant scripts require meticulous tweaking of your code and constant customization. You can spend hours working on a script only to find that the metadata API or Ant tool doesn’t fully support the Salesforce metadata type that you’re trying to deploy.
Change sets are even more manual. You have to remember all the changes that you’ve made or log them diligently. Many of the teams we talk to resort to spreadsheets and it isn’t pretty. Assuming you accurately capture all changes, you then have to create the change set manually. Many times it will fail to deploy if it’s an even moderately complex deployment. Worse, you have very little sense of why it failed so you have to go through an elaborate and time-consuming debugging process which involves creating multiple change sets. Trial and error is not a fun process in this context.
Blue Canvas makes this process much easier because it answers a key question: Why can’t I deploy? Blue Canvas automatically tracks changes so you always know at any moment what has changed and what is available to deploy. You can compare between any two orgs and create a deployment request with your changes. You no longer need to manually track down changes - this is especially useful when you have a few people working on the org.
Blue Canvas allows you to cherry pick which files you want to deploy and then run a metadata validation automatically. Because Salesforce deployments are complex, there is a good chance that your initial attempt at deploying will fail because of some dependency or difference in your target org that you didn’t foresee. With Blue Canvas, we show a clear log that states exactly which files are causing issues and why:
Our users have talked about how this alone saves hours. No longer are they manually trying to debug an issue. For example, you can see that the target org is missing a document that your deployment relies on. Now you know that you can just go upload it manually and the deployment will succeed. For example:
- Error in CustomApplication component My_Component’: In field: logo - no Document named Public_Images/My_App_Logo.gif found
If you see this error you know that the issue is simply the lack of that logo. So you can just upload the logo manually and automatically run the deployment validation again.
- Error in MyAction component 'SendEmail': Send Email is disabled or activities are not allowed. Enable Send Email and allow activities, then try again.
- Error in ConnectedApp component 'ContosoSSO': The consumer key is already taken.
- Error in ApexTrigger component 'triggers/Contoso_Account_Trigger.trigger-meta.xml': The specified Package Version number does not exist for that Package: FabrikamCatalog, 3.96
Once you’ve figured out what is wrong, you can rerun your deployment with a click of a button. No need to manually recompile a change set. You can also cherry pick out files that you want to ignore in the deployment and run again.
Salesforce deployments are still complex animals. There are so many dependencies you may need to include some manual steps. But the log that Blue Canvas generates will save you tremendous amounts of time, money and headache.
How Blue Canvas allows release managers and devs to deploy Salesforce components on a feature by feature basis.
How to use Salesforce sandboxes to set up a Continuous Integration workflow, plus how Salesforce DX affects sandbox management.