Salesforce Devops Journey

Salesforce DevOps Journey

Overview

Deploying new features from development to production within a Salesforce org presents a variety of challenges with its native tool known as Change Sets. Salesforce’s Change Sets primarily focuses on quickly promoting manually selected changes directly from a SaaS sandbox into production. However, it doesn’t provide DevOps capabilities you’d find in traditional software development such as versioning, collaboration, rollbacks, safety checks, and delivery tools.

From a business context, the problem with native Change Sets is exacerbated as teams scale, multiple projects run in parallel, GTM footprint expands thereby increasing the frequency of deployments and resource overhead dedicated to release management.

To solve the Salesforce deployment bottleneck, we’ve shifted Salesforce development teams from an org-based deployment (i.e. Change Sets) into a source-based approach leveraging third-party tools that were consistent with the engineering DevOps principles and integrating them into Salesforce with a custom-built app we’ve created.

The goals were as follows:

• Leverage the existing toolset for project management and source control
• Ensure the workflow process and products could be integrated with one another
• The final product should cater to both pro-coders and low-coders on the team (i.e. Salesforce Engineers and Salesforce Admins)
• Significantly reduce the time and resources spent especially on deployments. Eliminate the need for a Release Manager – this role is very common across many large Salesforce teams
• Provide transparency on code output and what we’re shipping – it’s common for Salesforce to be consumed by other engineering and technical teams.
• Adhere to compliance and security policies

Common legacy architecture and pain points

Prior to the shift to source-based deployments with our new app, a typical Salesforce deployment process from sandbox to production is depicted below.

Environments (Salesforce Orgs)

Change Set deployments

User Process

In the above scenario, each developer and admin manually track their items to deploy from Dev QA to UAT sandboxes. In addition, he or she documents the changes into the Jira sprint as well as a Config Workbook spreadsheet to help aggregate the entire sprint changes into one workbook. Once the sprint winds down, a release manager manually prepares a manifest from the workbook to ensure we have all changes to be deployed to production. Oftentimes it’s trial and error when there are many Change Set component dependencies for a given sprint that a release manager sorts out.

Limitations

• Environments as the source. Problem: Refreshes from production wipes away WIP and is all or none, thus any delays in refreshes will cause your environments to be out of sync
• Serial deployments, isolated development (we won’t see the conflict until final deployment to production during release review)
• Requires release overhead for each environment you deploy
• Component files can be overwritten by subsequent deployment
• Cannot effectively track dependencies or history of changes. (Spreadsheet requires manual input and has had discrepancies with actual changes)

Shift to Agile

• The current approach became much more problematic with the introduction of Agile bi-weekly sprints. Previously, there wasn’t a process to ship to production before the CRM Engineering team was formed. Features were shipped ad-hoc and driven by stakeholders

Custom DevOps Solution

We achieved the goals of the project by shifting to a source-based deployment model with GitHub, Salesforce CLI, and JIRA and building a custom app on the Salesforce platform to integrate everything together. The solution brings engineering DevOps best practices into Salesforce and allows pro-code developers and low-code builders to work together in a repeatable and scalable way.

Current architecture

The new architecture for Salesforce deployments leverages source control as the primary mechanism to develop and deploy changes. This provides native benefits of source control such as backup versioning, collaboration & transparency around commits/pull requests, and a single source of truth for code/XML configurations.

The custom Config Workbook App is built on the Salesforce Production org leveraging Lightning Web Components. The app provides a few essential features:

• It automatically syncs all of the production path environments between the Salesforce org environment and its respective branch in GitHub
• Integrates directly with the JIRA Agile project/user stories with the associated Salesforce metadata components. This facilitates with audit and documentation of each change
• Provides an easy-to-use path for low-coders who may not be familiar with Git to easily deploy their point and click changes directly from the app to the production path environments

App UI

Results

Admin and Developer benefits

• Reduces manual work on developers for adding their components to Google sheet workbook, in Jira and in Change Sets for deployment. This saves a lot of time for development teams so they can concentrate more on build.
• Deployment between environments is a click away of spending hours creating Change Sets and moving between environments.
• Automates and maintains compliance (e.g. SoX) tracking and eliminates manual tracking.
• Easily identifies potential conflicts during build.

Company benefits

• Cost savings and greater consistency with the broader engineering organization.
  • Tools already in place and adopted by border engineering: GitHub, JIRA.
  • Eliminated the need for a dedicated full-time release manager
  • Reduced deployment to production from 1 day overhead to a few minutes
• Process optimization
  • Simplified and improved the velocity of the sprint process. Ship builds faster to QA, and stakeholders for immediate testing.
  • Increase developer and admin feedback loops earlier in the build process
  • Allows us to develop in parallel with multiple projects and at difference cadences
• Cross collaboration
  • Admin learning opportunities to see how their point-and-click changes translate to code/XML
  • Eliminate silos between admins and devs
  • Code is visible to stakeholders in Data, Product, and Engineering for wider collaboration and opportunities for integration
• Security and compliance
  • Security and privacy team may have strict guidelines and much more limited use cases with 3rd party Salesforce DevOps solutions. Thus, the in-house custom tool provides greater automation and integration with a company’s PM and source control tooling.