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
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.
We then started the work to provision the various tools and configure them to create a seamless process for Continuous Integration and Deployment (CI/CD). As we worked on these items, we completed this work in a couple of sprints and managed this body of work through the ADO board.
Adoption and Other Success Metrics
We also involved the client team of developers, administrators and scrum masters as we did the work. In addition to formal demos, we had multiple “who and tell” sessions. The idea was not just to show that we did the work, but to demonstrate how work gets done.
We also worked with the client as they used the new process and tools to perform releases with new features, hotfixes and backporting changes to the various environments. We also practiced how to do a rollback should it become necessary. This significantly reduced the effort we had to spend in training while increasing confidence within the client teams that the process works for them.
Furthermore, we worked with the client team to baseline and continuously measure the following metrics.
1. Time taken for the delivery of a feature from concept to release in production
2. Time taken to recover from a software failure
While we could see that the new processes are faster and safer, the degree of improvements will become apparent over time.
We also developed a comprehensive DevOps training manual for the customer’s team, enabling them to use the streamlined processes and tools effectively.
Hope you liked this post. We would like to know how you use DevOps to add new features to your Salesforce org.
Why Choose Solunus to Implement Your DevOps Project?
Solunus is a dedicated Salesforce partner organization, headquartered in Dallas, Texas. We have highly competent, dedicated Salesforce DevOps professionals serving prestigious customers. Our team has rich experience in Salesforce DevOps implementation services for firms of all sizes across the industry spectrum.
Customer Satisfaction (CSAT) score of 100% from all clients
5 star Salesforce AppExchange rating for all projects
Strong focus on comprehending your unique business requirements
A robust, proven process that can be fully customized to meet specific needs
