top of page
Search

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.

 

Project Overview

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


Implementing Salesforce DevOps for Logistics Challenges
 

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.