Blog Detail

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

About Solunus

Solunus is a dedicated Salesforce partner organization, headquartered in Dallas, Texas. Our unrelenting focus on comprehending the unique needs of our clients coupled with our unrivaled expertise of the Salesforce platform enables us to deliver the perfect solutions that create the best value for IT and business analytics firms.