Dear Force.com Admins,
You probably have to meet a deadline when your users will get to use the cool new features you provision with the next deployment. But what if the deployment fails? Then you will miss that very deadline.
Did you know you can easily break Force.com deployment runs for your org?
Read on to learn why customization changes can break deployments and the recommended preventive measure. This procedure applies to enterprise or unlimited editions.
An Introduction to Breaking a Force.com Deployment
As a Force.com Admin you get to use all the cool tools to easily customize an org:
- Data model tools for management of Custom Objects, Custom Fields
- Workflows for management of Assignment Rules, Field Update rules
- Record level access rights by managing Sharing Settings and Sharing Rules
An org also contains custom APEX code developed to implement your companies custom business logic. Salesforce.com enforces that at least 75% of APEX code must be covered by Unit Tests – best practice obviously is to cover more.
In short: If there is APEX code, there are unit tests.
A best-practice unit test follows this flow of operation:
- Create test records (e.g. Accounts, Contacts, Opportunities, Custom Objects etc)
- Apply business logic to the test records
- Verify results (Test succeeds for correct result / Test fails on error conditions for incorrect results or data)
If you initiate a deployment to your production org the Force.com platform will „Run all tests„. By doing that it verifies that every business logic previously deployed to your org will still work as intended (tested by Unit Tests) even after the change, before it potentially breaks functionality for your users. A deployment will be aborted and rolled back if any unit test fails. The Force.com paradigm is to „Keep the system running“ because it obviously is impossible to „Never touch the running system“…
The Breaking Changes
How do these worlds connect? How can a Force.com Admin, using her tools, break the unit test a developer wrote? Some examples:
|Breaking change||Impact||Potential solution|
|Change a field (custom or standard) to be always required||Unit test code that does not fill this field when creating test records will fail to create the records. Most often seen in the wild with custom fields that were not required to begin with.||Change APEX code to populate the required field OR make the field optional again and use the page layout to make the field required. **Check if error message is available to quote**|
|Change sharing settings for records e.g. to private or change who can read / write which records.||This is a subtle one. If the unit test is written according to best practices and running in the context of a non-Sysadmin Profile, access to the record might be denied by Force.com to the very unit test that created it.||Adapt the APEX code to know about the new business requirements regarding data visibility. By the way, this can be a very subtle on to debug for developers. Potential error message: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insufficient access rights on cross-reference id:|
|Add/modify a Workflow Field Update Rule that interferes with unit test data. Applies to Approval process rejection or approval steps as well.||The automated unit test will not see the expected data – and fail. What to do: Adapt the Workflow rule to not interfere with the unit test case or adapt the APEX code to know about the new business requirement the Field Update implements||Modify the entry condition of approval processes. Impact: if unit tests need to trigger an approval and the entry condition does not match anymore, the test will fail b/c no or the wrong approval process fires.|
What to do about it?
Why is it so easy for a Force.com admin to break deployments? It is a great thing to have the admin tools at hand and be able to implement and provision changes for your users quickly. But in more complex Salesforce Orgs the Force.com Admins need to be aware of potential conflicts and manually „Keep the system running“:
Any Admin can execute unit tests – any time! Make use of the test execution.
- Run unit tests before change to verify everything is fine
- Make your change
- Run the unit tests again to verify everything still works.
Once this pattern is used reliably, you might decide to not run tests prior to your changes. In case your change breaks any unit test, developers will love that the single breaking change is known – that eases the process of adapting to that change a lot.
Happy testing & Succesful deploying!
- Salesforce Help on „Running Unit Test Classes“ – http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_testing_unit_tests_running.htm
- An Introduction to Force.com Environments (Sandboxes) – http://wiki.developerforce.com/page/An_Introduction_to_Environments
Neueste Artikel von Lukas Schroeder (alle ansehen)
- Datenqualität in Salesforce: Messung, Relevanz, Optimierung - 3. August 2017
- Force.com: Malformed Error Messages due to HTML code? - 30. Juni 2013
- Force.com Admins – The Power to Make and the Power to Break - 5. März 2013
- Mit Force.com Sites den Partner Portal Login customizen - 26. Oktober 2012