Implementing Salesforce DevOps at a Logistics Firm to Deliver More Value
For years, IT organizations within large enterprises have struggled with balancing two seemingly conflicting goals while introducing new capabilities.
Time to Market: Getting new features deployed into production quickly
Stability: Any change introduced into a system causes some disruption. It could be availability – systems being down for short intervals and features that used to function no longer work. Companies may also need to train their people on the change.
DevOps, as a discipline, came into vogue to bridge the conflict between the two IT teams responsible for these goals, viz, development and operations. The requirements of a modern business evolve quickly, and this calls for the ability to add new capabilities to its software systems rapidly and cater to the needs with minimal disruption to its operations.
DevOps has matured and is being practiced in most software development shops that develop code in a high-level programming language like Java or C#. However, it is not as widely adopted in low code/no code environments like Salesforce.
Here, we’ll see how our team helped a leading logistics provider realize greater business value using DevOps for their Salesforce system.
About the Client
The client is a well-known provider of logistics services with headquarters in the USA. The company has been providing customized moving and storage solutions across the USA, the UK, Canada, and Australia.
The client was facing various issues with one of their Salesforce applications, which caused problems in ensuring the successful delivery of goods. The firm sought our assistance in fixing the issues and acquiring the capability to enhance its delivery processes to meet its ever-evolving needs.
Challenges Faced by the Client
Salesforce DevOps Solution Provided by Solunus
Before proposing specific solutions, we undertook a discovery exercise to:
Understand the customer’s existing IT landscape
Know the tools they had invested in
Learn about processes they follow and the level of their efficacy
Finally, we took time to study the company culture, maturity of the development team and their appetite to change behaviors.
This enabled us to comprehend the problems faced by the client thoroughly
Here are some findings from the discovery phase
Degree of customization > # Apex Classes; # LWC/Aura components
Typical number of changes in a release
The customer had licenses for Azure DevOps (ADO), Git, and Confluence
ADO board was used to maintain the backlog, but it was not effective in refining the backlog and updating status
Coverage from unit tests in lower environments were lower than the 75% mandated by Salesforce
Deployments were done using change sets that were created manually
Lots of manual effort was spent in: > Tracing a change made in the system back to a business requirement > Comparing Salesforce metadata across two sandboxes – for example, Dev and QA > Back propagating changes made directly in production back to lower environments > Creating base data in the development environments > Verifying code quality and security violations when it was done
We identified the lacunae in their current processes and systems
Our team determined the feasibility of automating their processes; we identified the scope for automated releases and automated sandbox management within the current architecture
We also developed a robust system to facilitate hassle-free communication between different teams
Our experts ensured complete security of sensitive business data during the Salesforce system enhancement
We shared our findings along with a set of recommendations with the client. The recommendations included:
Using the Azure repository (Git-based) to version and store Salesforce metadata
Use an off-the-shelf tool that automated Salesforce deployments while integrating with GIT and ADO. We evaluated multiple tools and suggested the one that best fit the customer’s use case
Having a process to manage the various environments > Guidelines on the number of development sandboxes, QA and UAT and the type of sandbox needed for each > Processes and schedules to provision, refresh and deactivate sandboxes > A mechanism that maps the features being developed and the sandbox to specific branches in Git > Branching strategies for feature development vs. hotfixes that take into account parallel development > Mechanisms to seed data in each of the environments and mask data wherever appropriate
Approach to Release Management > Mapping releases to environments and Git branches > Configure the ADO board and reports to provide visibility on the status of each release; the work items in each release and the status of each of the work items > Planning internal releases around the scheduled platform releases from Salesforce
After some discussion on negotiating the sequence of activities, the client accepted our recommendations. We worked with the tool vendor to provide a trial edition of the deployment software while the client’s procurement group went through the process of securing the licenses.