This post was written in collaboration with Close Brothers Motor Financefollowing an engagement to design and implement a Release Management approach and DevOps tooling to support a new Salesforce delivery team.

A very Salesforce problem

One thing everyone loves about Salesforce is the low entry point required to begin customizing the platform. The availability of ‘clicks-not-code’ tools capable of complex automation has meant functionally aligned individuals are empowered to build custom solutions typically only a Developer could dream of. Because of this, Salesforce has created a space where Admins and Developers can comfortably coexist in a delivery team.

The challenge, however, comes when those Developers have become accustomed to a mature deployment approach, often harnessing custom-built pipelines on the various CI/CD suites available. As a DevOps fanatic, I’m guilty of favouring custom pipelines given the freedom gained to finetune the deployment behaviours; and scale all the awesome Salesforce CLI plugins based on the requirements in front of me.

Typically, this creates a need for having an SFDX project in source control; with developers committing changes according to a standardised branching model in order to trigger pipelines in a structured manner. But since most Admins aren’t familiar with such practices, therein lies our problem. The team has a fantastic DevOps approach, but it’s not accessible to our functional team members.

Close Brothers Motor Finance made a strategic decision to invest in Salesforce. A new team, newly trained with Slalom were engaged to improve our development skills, maturity, and throughput for Salesforce changes. One of our key responsibilities is to face into the reality of a situation. Manual processes, large changes, changing environments with lots of manual steps means something is going to break. Customers and developers frustrated with time and goodwill lost. A well-trodden path. It shouldn’t be like this. We needed to review the type of work we were doing, how we were delivering and automate as much as possible.

Analysis discovered that a large volume of changes involved simple modifications that, in reality, do not need the skills of a developer. For example, changing the content of a drop-down box, field labels, or a page layout. We realised we became constrained not by the number of developers we had, but by the number of people who could safely and consistently package changes up for deployment into production in a repeatable, automated way.

In summary, our requirements were: develop a process that will standardise our DevOps approach, so all changes go through the same process, empower non developers to make simpler changes to increase our velocity, and automate as much of the process to avoid manual errors.

- Matthew Lill, Senior Delivery Manager, Close Brothers Motor Finance

An Ecosystem like no other

Most Salesforce professionals will agree, that when faced with a problem, an essential step in the journey to finding an optimal solution is to review what the Ecosystem has to offer. It’s easy to jump to architecting a custom approach, but it’s potentially time wasted if you realise you’ve reinvented the wheel further down the line. The rich and diverse range of AppExchange products, partner tools and accelerators are one of the many things that sets the platform apart in the CRM market. Furthermore, the DevOps space is certainly no different — with a wealth of options available for teams looking to transform their deployment strategy.

One of the most exciting verticals, in my opinion, is the 3rd party tools offering complete DevOps solutions to all members of Salesforce teams, regardless of technical capability. These tools vary in size, with some being very targeted to simply moving changes from one org to another; all the way up to offering an entire suite of Release Management solutions.

Our requirement was more aligned with the former. Other delivery teams had set the company standard of using a very popular open-source automation server for deployment pipelines, and with central support for creation and maintenance available to the team — pitching an entirely new suite (and the related license costs that come with it) was unrealistic. We also wanted something that could scale up and down easily, to support a dynamic team setup. However, most crucial was that it would complement the existing landscape without any complex integrations; primarily support for self-hosted source control using GitLab.

Following an analysis of the market and several vendor demonstrations, we landed on Gearset being the best fit.

In a previous role, I’d had experience using Gearset’s org comparison functionality and recalled describing it to colleagues (perhaps somewhat poorly) with the analogy “change sets on steroids”. More accurately though, Gearset, along with many other capabilities, enables a powerful metadata comparison between not just a Salesforce org, but also scratch orgs and most importantly: git branches. The comparison results are presented in a super intuitive interface, highlighting differences in several different views (because reading XML is never particularly fun); empowering the builder to pinpoint their changed components as part of a ‘feature’.

The cherry on top: Gearset supports connection to on-premise source control with GitHub, Bitbucket and GitLab; in addition to any custom git-based repository via username and password.

For many, if not all IT teams, source code is alike to the crown jewels. Secure networks, firewalls, certificate-based authentication, role-based access control. Exposing our on-premise Gitlab instance to a cloud hosted SaaS product like Gearset was always going to be an interesting challenge. Especially as we operate in a regulated industry and are prudent when it comes to risk management

We opted to use a Web Application Firewall/API Gateway between Gearset and Gitlab. This ensured we weren’t exposing our Gitlab servers and allowed our Sec Ops teams to monitor the integration for any unexpected events.

I believe this was the first time the Gearset team had seen source control secured in this way. We took them through our proposed approach and their live chat/telephone support was efficient and valuable.

- Brad Gyton, Senior Solutions Architect, Close Brothers Motor Finance

A design, accessible to all

Developers love harnessing the latest and greatest tools available to them. Therefore, the prospect of being able to create a disposable environment, perfectly reflecting their source code in a matter of minutes, is a no-brainer. So for the folks who know their way around an IDE and are comfortable utilising the Salesforce CLI; we designed Scratch Orgs to be the start of the process.

We chose to use the Gitflow branching model (an approach shared by other delivery teams within the company), meaning developers would build features in their scratch org and then merge to a ‘develop’ branch; triggering a deployment to a continuous integration sandbox. This lifecycle is something I imagine most developers are comfortable with. The ‘develop’ branch then contains the latest code base and the next developer is ready to push it to their Scratch Org, and a release can be cut when the time is right.

But what about our functional folks wondering “what the hell is a CLI”? For those team members, we wanted to keep their building experience as close to their comfort zone as possible. In reality, these individuals wore multiple hats (such as the type worn by Business Analysts) so we couldn’t expect that learning SFDX commands would be their priority. As such, we prescribed they would continue to build in Developer sandboxes. Typically, this would cause a challenge since those sandboxes are going to very quickly come out of alignment given developers are working in Scratch Orgs. Enter, Gearset.

Armed with Gearset, before they began building in their Developer sandbox, step one would be to do a comparison against our continuous integration sandbox. If someone had just deployed a feature, they could quickly identify the components which had been changed and deploy them to theirs. Knowing they now had the latest code base and were effectively aligned to the ‘develop’ branch in the same way a Scratch Org would be, they can go away and build their feature with confidence.

Once they are happy with their changes — they jump back into Gearset. Now rather than simply doing a comparison against two Salesforce orgs and then deploying their changes, we designed a workflow centred around being unified with how developers were working. Most importantly was that features were merged into the ‘develop’ branch, so that cutting releases captured everything and even features built by Admins could then be pushed to scratch orgs.

Therefore, with Gearset connected to source control, team members can create a feature branch without even leaving the platform. Great! One less tool they need to learn how to use. Remember how metadata comparisons in Gearset also supported branches? Well comparing their Developer sandbox to their feature branch would identify all the components they’ve just changed, exactly what a developer experiences when they execute a force:source:pull.

Since their Developer sandbox was recently aligned to the ‘develop’ branch too, their list of changes didn’t contain a long list of unknowns. Once they have hit the tick box next to their changed components, Gearset makes it simple to commit them to their feature branch and can even manage the creation of a pull/merge request.

Throughout my career as a Business Analyst, my role fundamentally takes business requirements and provides these in a format that the developers can understand and build. Gearset has enabled me to take those requirements, build them myself and release these through environments efficiently and securely. This is such a huge change in the role of the Business Analyst — decreasing the time taken to receive a change request and implementing that in Salesforce with minimal risk of misinterpreting the requirements — since I am the one who is gathering them, developing them, and releasing them!

What a difference it has made, with so much potential realised in the few months we have been using Gearset.

- Ryan Gascoyne, Senior Business Analyst, Close Brothers Motor Finance

At this point, the Admin has interfaced with the project’s repository using an entirely different set of tools developers would; but has reached the exact same end state. The pull/merge request is sitting ready for a developer to peer review and merge and with the metadata changes in source control, the custom pipelines can interact with them however the team desires. This means all the features which have been developed are in one central place, ready to be pushed upstream in one unified release approach.

Like the concept? Some considerations

This type of workflow isn’t typically how Gearset is used. Most will be using it for their entire CI/CD and pipeline management/orchestration. Therefore, there are a few things to keep in mind.

Is your team maintaining a package.xml as new customisations are made? If you’re using another CI/CD tool as described above, Gearset isn’t capable of determining the approach your team is taking (be it delta or full deploys). To manage this, whenever a developer was peer-reviewing an Admins pull/merge request, it was their responsibility to modify the package.xml where necessary. Many VCS’s have a built-in online code editor, meaning they didn’t even need to leave the browser tab they were on. Of course, Admins could also be responsible for this activity, though in our case, that would have added one more tool for them to learn how to use. Don’t forget, Gearset had taken care of creating the git branch and pull/merge request. If you’re not already, you could also automate the need for new components to be added to the package.xml. Check out this awesome SFDX plugin which will do the hard work for you.

Does your team have some fancy pipeline capabilities? Even something like static code analysis is going to add a layer of complexity to making pipelines accessible to non-developers. Review each of your pipeline’s stages and determine whether a tool like Gearset committing to feature branches is going to cause challenges. Many such challenges will likely mean there will be an increased focus on feedback between a developer and non-developer during the peer-review process. Not problematic, though your developers may see this as a hindrance, so be creative.

We hope you’ve found our approach insightful.

Had a similar challenge? We’d love to hear how you tackled it in the comments section. Don’t forget to follow for future content on the Salesforce DevOps space!