Salesforce Assessments for clean up.pptx

Assessment of salesforce

1. DevOps Assessment & Proposal

2. 2 Back Promotion Hotfix Process complexity because of the 5 code bases 4 code bases in parallel. + E2E fixes in large volume Team is under-staffed, focus on the releases instead of back promotions Stop the development work and then focus on the code merge conflict. Volume of the user stories New deployment in release fix Orgs which is forcing more hotfixes Major functionalities are included in the hotfixes. Security/Penetration testing fixes were done in Release Code scanning issues (700-800 changes in Release) Performance optimizations are included in hotfixes to improve system efficiency

3. Automation Opportunities T-Mobile & Salesforce Recommendations Reducing the number of environments running in parallel to streamline processes. Current setup includes 2 E2E, 1 SIT, 1 Dev, and Production environments, with 5 active branches. Maintain the current strategy and avoid adding more environments. T-Mobile recommends having 2 SIT environments for improved testing coverage. Manual pre- and post-deployment steps currently take 3-4 hours, highlighting an area for potential automation. Activating LWC (Lightning Web Components) could benefit from automated processes. Insufficient time for thorough smoke, regression, and performance testing indicates a need for automation. Implementing proper CI/CD practices can extend automation to these critical testing areas, enhancing efficiency and coverage. 3

4. 1 2 3 4 5 6 7 2 3 4 5 Hotfixes are done in the E2E Org, leading to missing user stories in regular development planning. There is no dedicated environment for proper end-to-end testing in QA and SIT. Lack of a suitable environment for proper defect fixing identified in later stages due to end-to-end testing constraints. The E2E ( PreProd ) environment is also used for training purposes, adding to its load. 1 We have only one development Org, limiting the ability to handle multiple release deployments from a development perspective. Last-minute refactoring changes in Release fix are complicating the deployment process. Removing certain functionalities from E2E bundles proves to be extremely challenging. The frequency of monthly releases is resulting in more deployment-related issues. SFI URLs lack parameterization, potentially hindering scalability and maintenance. Initial focus on packaging user stories sacrifices flexibility but ensures consistency, emphasizing early planning. QA lacks integration with desired third-party applications, causing issues during end-to-end testing. Corrupted JSON files and permission issues are being addressed manually in Git, leading to inefficiencies. General Observations Org Infrastructure

5. Gov – Cloud 5

6. 6 User Stories Monthly Releases March 01 April 02 May 03 Deployments of user stories on monthly basis User Stories: 700 User Stories: 210 User Stories: 200

7. 7 Current Model – Flow of Deployments Deployment is done using bundles in Copado instead of using individual user stories. Bundles are first created in the QA Org. Git history is preserved across all environments. Org refreshes are avoided to prevent downtime. There are five code bases due to parallel release cycles. Monthly releases follow aggressive project timelines. Typically, there are over 200 user stories in each monthly release cycle; March had 700. Pre- and post-deployment steps require 3-4 hours of manual effort.

8. THANK YOU