I’ve had the opportunity to work in both Microsoft Dynamics™ CRM and Salesforce.com™. Both of these enterprise business applications are excellent customer relationship management tools and offer the ability to customize the systems to meet the client’s business needs for business process flow, high level business intelligence dashboard reporting and a customized user experience that tailors itself to the business process as well as the business rules of the client’s organization.
One of the common challenges is keeping your development environment in sync with the production environment. Coding in a development environment that is not in sync with production can lead to many hours of frustration trying to find the ghosts in the code. I find this especially true working in Salesforce.
Salesforce has some very tight restrictions in place to guard against flawed code, which could potentially affect many parts of production from getting into the system. I believe they have put these ‘hurdles’ in place because they are strictly a cloud–based system and access to the ‘belly of the beast’ is not available to the developer. Some code can be promoted to production with a simple cut and paste. For example, JavaScript code behind a form button can be copied from a Salesforce sandbox development environment, and pasted directly into the production environment.
However, Apex triggers can ONLY be developed in a Salesforce sandbox environment. Then a test Class and test Method must be developed in order to test the outcome of the code. Salesforce also requires that your test Method hit a high percentage of the actual code that is in the trigger. This is referred to as Code Coverage. Once the trigger code has passed Code Coverage and the test against the Method(s) are successful, you can then create an Outbound Change Set to send the code to the production environment. You then login into production and query Inbound Change Sets to find the one you just sent from the development environment. However, the code still has to be validated in production before it is actually deployed. This can be the big gotcha. If changes to production were made since the last time the development environment was synced from production, your code could fail production validation and be un-deployable. Then comes the pain of finding the delta between development and production in order to be able to troubleshoot the code in development so it will pass production validation tests.
There are times when it is better to save off your code from the development environment, sync production to development, then paste back in your code and begin the troubleshooting. However, this should never be done unless you are completely confident that nobody else is mid-stream with other development items or issues.
For more information about this blog or C5 Insight, please contact us here!