Salesforce Code Move Strategy
Aug09

Salesforce Code Move Strategy

Why sometimes a few lines of code changes take several days of deployment. Find the answers and Code Move Strategy:- Recently In one of my project I faced the following situation: We did a code change in trigger. Changed a string value from “Demo” to “Trial”. The code change hardy took 1 minutes. Client was aware of the changes and  time it will take so we estimated the work as 2 hour including code changes, analysis of its impact and deployment. When the developer finished deploying the code changes it took him 2 days (16+ Man-hours). Yes it is a surprise. Now let me list out the problems he faced.   Code coverage of the existing trigger was 12% (Our Company Best Practice is 85%) Code coverage of overall production org was less than 75%. Yes this is hard to believe but this do happen when we push things in production without code coverage. Existing test classes were failing in production. Trigger in production was different than in Sandbox. Yes this is also possible when we have multiple sandboxes and people do code overrides as they are competing against each others. Deployment had a narrow slot of 2 hours during which end client were not working. Batch Jobs working on the same object were preventing the Trigger to deploy. We gave our best as a team and came up with the following strategy which changed our entire company’s estimation and requirement analysis process. Code Move Strategy: Step 1: Check the existing production code coverage by “Run All Test”. Step 2: Lookout for test class failures if any. Step 3: List out the Batch jobs running in production. Step 4: Compare the code between production and sandbox before working on it. If any differences found report it to your end Client/Manager. Step 5: Make sure if you are deploying an apex code its code coverage should be above 85%. Step 6: Use Changeset for small size deployment with less components. Keep the changeset names in a well defined order. Step 7: Use Eclipse or Ant Migration tool for deployment with many components.If you have the privilege of Full copy sandbox use it for trial deployment and go live. Full copy sandbox gives you an advantage of less risk more effort based deployment process. Step 8: Deactivate the necessary batch jobs and validation rules before deployment. Step 9: Make sure the deployment is in the right time slot when end users are not working or keep the team informed for any surprises that may come while deployment or after that. Step 10: Validate and Deploy. Reactivate the Jobs, VRs etc. Step...

Read More
7 Checkpoints for Salesforce Developer
Apr24

7 Checkpoints for Salesforce Developer

As a Salesforce developer you are supposed to take some mandatory precautionary measures for development, testing and deployment. Development in itself could be a complex job. We should be careful enough while we are designing the UI or implementing any business logic. This piece of advice can be a long list of Do’s & Dont’s but I will be summarizing the top 7 domains under which a novice or a seasoned developer can make mistakes. Trigger: Less Code in Trigger: Business logic should be written in Apex classes and purpose of writing a trigger should be to divert the various update, insert, delete, before, after control flows to the correct Apex class. Context-Specific Handler Methods should be their in Apex classes. Bulkification. While developing a fresh trigger we should always think of the possibility that the records in the object can be inserted, updated, deleted by a User in bulk using API, Data Loader tool or custom Multiple edit page etc. NULL Check: This is a very basic check which every developer learns in the course of testing triggers which they developed. One Trigger for One Object: Creating multiple triggers on the same object will cause warnings in Checkmarx code review for Appexchange. Self looping triggers: Beware of this and make sure you use a Static field in class to verify the trigger is not getting called multiple times. Webservice callouts from Triggers: Can’t hit more than 10 callouts at a time. Design Patterns are good solution for this. Trigger Frameworks and Apex Trigger Best Practices Visual Force: SOQL: Make sure the query is having a limit or an intelligent WHERE clause. A query can be written in Salesforce in multiple ways. Design: If the Logic permits then use components and divide the screen in separate pages or Wizard steps. Use Static Resource for all the CSS and images. Separate JQuery, Javascript files will also be good. Check View-state: Make sure that the Salesforce view state size is always in check. Action Tags: The lesser number of action tags the less will be callouts to Salesforce controller(Server). Most of the simple business logic/validations can obviously be carried to client side scripting. Best Practices for Improving Visualforce Performance Web Service: Commit Rollback exception. This should be taken care of SOAP: We should have the clear understanding of WSDL we are going to use in Salesforce. Web Service, parameters, range and return value. SOAPUI is one of the best desktop based tool to do a dummy test. WSDL FILE size limit may some time demand trimming: Will need WSDL expertise for this job. REST: The services resources should be identifiable and...

Read More