The journey to a more agile, automated release process with Gearset’s Pipelines
Overview
We spoke to a global goods manufacturing company using Gearset to build on Salesforce. The company has four core business operations, each with their own Salesforce production orgs that are used to manage customer data, marketing, lead programs, and more.
These Salesforce orgs have a significant number of custom objects that help selling partners to interact with Salesforce data, and unlock other integrations such as the ability to track shipments.
The Salesforce orgs are managed by a team of 11 developers, 5 analysts, 4 admins, an architect, a project manager, and a program manager. As they are distributed all around the world, the team use Jira to work collaboratively.
The search for a robust deployment solution
The team originally invested in Gearset because they needed a comparison and deployment tool. When starting out with Salesforce, the team followed a manual deployment process that costed precious time and meant changes could take between four and six weeks to reach production. They later adopted change sets, but this also fell short of their requirements — they needed a more robust tool to help with their Salesforce deployments.
After trialing a couple of options they settled on Gearset, which quickly improved their comparison and deployment processes, and also allowed them to deliver even complex data models in a fraction of the time.
Gearset kick-started an evolution
While Gearset revolutionized the team’s deployments, it also helped them to discover how version control could benefit their operations. From there, they went on to explore Gearset’s continuous integration solution.
Initially the team would commit all development work to one branch, which they’d then automatically deploy to QA and UAT. When their architect pointed out that it wasn’t best practice to promote everything to QA and UAT immediately, they decided to create several CI jobs for each of the five levels of their deployment process. With this new setup, issues can be caught earlier and isolated to upstream environments, rather than reaching UAT and blocking other work.
After improving their deployments and automation, the company expanded their use of Gearset to include data deployment tools, following a conversation at Dreamforce with Kevin Boyle, Gearset’s Co-Founder and CEO. “Gearset is super engaged with its customers, and that’s something we’ve found from day one. Being able to walk up to someone and get results… that’s a huge advantage.”
Data deployment has made it easy for the team to seed sandboxes with accurate test data, as well as match data sets between QA and UAT, especially when deploying new objects.
Great support on the learning journey
Gearset was central to the company’s learning process to get to multiple CI jobs and enable truly agile deployments. Too often, other tools they tried would give them a solution to an issue without providing the education they needed to understand why it happened and how to avoid it in the future.
Lightning-fast deployment times
Gearset has rapidly improved deployment times. If the team are working on a custom object with 8 or 9 metadata types, it takes under 15 minutes to compare and deploy from the org to the branch. The average run time of their CI jobs is now under 10 minutes after previously taking up to 45 minutes.
This means that work can be deployed through the entire four-stage pipeline in under an hour. This is a huge improvement on how they were working before, and they are still finding ways to increase the speed of that process even more.
Pipelines: the final piece of the puzzle
In 2022, the team plans to have as many as 7 parallel dev environments. This would normally be incredibly difficult to manage — but Pipelines, Gearset’s Salesforce CI/CD functionality, has made it easy.
The branching and merging opportunities in Pipelines allow the team to work on multiple branches at the same time, test as they go, and make sure there are no conflicts between branches.
The development team work in Visual Studio and Visual Studio Code, employ SFDX commands, and use Bitbucket as a Git hosting provider.
Gearset’s Pipelines view automatically reflects all these changes, and using Gearset’s automation API the team are able to receive back any error messages of conflicts or failures, without changing where or how they’re working.
A new, improved deployment process
Previously, all changes needed to be checked and compared manually by the Senior IT Analyst before deploying to UAT. Now, thanks to Pipelines, developers are able to merge their changes themselves.
A phase gate then carries out additional unit tests before changes hit UAT, which in turn allows colleagues external to IT to do their own tests to make sure the changes meet their needs. As soon as all these tests are passed, the analysts are able to see the changes queued for the master branch and can authorize the merge.
The next step for their workflow is to decide when to back-propagate changes. Pipelines can do this automatically, but the company needs to establish if it’s better to do this at the phase gate or when merging with master. The final stage of deploying to production is still done manually, so the team can make sure the business is ready for the changes to go live, and also check it meets the change controls and auditing requirements.
The team currently releases two to three times a week, although their ambition is to bring that up to daily releases, and ultimately they believe Gearset will enable them to make this goal a reality.
The Pipelines view is so valuable and central to their processes, it has now become the Senior IT Analyst’s default screen in Gearset:
Calculating the ROI
In order to understand the value that Gearset — and in particular the Pipelines feature — is bringing to the company, they are calculating how much time was previously spent on manual comparisons, waiting for commits and merges to happen, and fixing conflicts. The savings are huge.
What advice does the team have for other teams about to embark on embedding automated deployment processes into their Salesforce development?
There’s going to be change, and teams need to invest time in learning new processes. But once these processes are understood, it isn’t difficult to get things up and running.