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.  

  1. Code coverage of the existing trigger was 12% (Our Company Best Practice is 85%)
  2. 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.
  3. Existing test classes were failing in production.
  4. 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.
  5. Deployment had a narrow slot of 2 hours during which end client were not working.
  6. 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.

strategyCode Move Strategy:

Step 1: Check the existing production code coverage by “Run All Test”.

Run_All_Test

                                                                    

Step 2: Lookout for test class failures if any.

Step 3: List out the Batch jobs running in production.

job

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%.

Code_Coverage

Step 6: Use Changeset for small size deployment with less components. Keep the changeset names in a well defined order.

Change_Set

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.

Using Eclipse _Tool

Code Move Strategy

                                                                Code Move Strategy

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 11: If possible test the deployment in production or ask the respective feature manager to test it in production and report feedback.

Image

Features Ant Migration        ChangeSet   Eclipse  
Big Size Project with 200+ Components Y N Y
Small size changes with less than 10 Components(Page Layouts, Data Model, Validation Rules, etc) N Y N
Code comparison: Compare the code before deployment N N Y
Quick deployment: We need a deployment done within 5 minutes. Y N Y
Non related org: Different Salesforce Organization Y N Y

 


Author: AJ

Share This Post On

3 Comments

  1. Hi Ajay,

    Deactivating batch jobs and workflow may not work for Organizations working in multiple regions with different time zones. Its very hard to communicate the impact this may have with the end users using the system.
    Validating the deployment one day prior to the deployment will give a better picture of what may fail and work on it.

    Post a Reply
  2. Thanks for sharing. It is indeed important in which order you do this in, as stated in your post.

    It is always good to keep as much metadata as possible, at least: apex classes, triggers, VF-pages and components, Lightning components, profiles and permission sets, custom objects and custom fields in Git and use a simple but effective branching scheme. What’s in Git is the truth. Each developer needs their own sandbox. To prep your dev box before creating a feature make sure to pull latest dev branch from Git and deploy that to your dev box using Ant. Then create a feature branch and create your feature. When done and tests are ok, merge your feature branch into dev branch (after code review by other developers) and deploy to your integration sandbox (maybe automatically using a CI tool). By using Git as the source of truth, you will never end up in developers overwriting other developers code in a box 🙂 Changes in custom objects and fields are easily added to git by first retrieving the metadata from your dev sandbox using Ant and then use Git to spot the changes made 🙂

    Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *