Language
.webp)
.svg)
.svg)
Everybody loves the idea of automation. When implemented effectively, it’s easier, simpler, and a whole lot more efficient.
However, as with any other type of tool, deployment automation tools need to be fully understood if they are to be used in an efficient manner.
Deployments, in their simplest form, are merely moving changes from one environment into another. Given the hidden dependencies that often exist, this can provide a unique challenge within Salesforce. Even when these dependencies are not a factor, automation remains complex.
There is no shortage of questions that pop up, too: When do you trigger a deployment? Who has the right to initiate it? What changes are deployed? Is it just a single feature, or everything in the Release Branch?
Unfortunately, many DevOps teams get a little overexcited about using Jenkins or other tools to ease the burden of deployment before realizing the complex issues that go with it. This misunderstanding can lead to a litany of problems further down the road.
With that in mind, this article examines some of the key concepts that must be considered when automating Salesforce deployments to help you and your team squeeze every last drop from your tools.
Let’s get to it.
Let's start with Quality Gates.
Should every change be deployed or only those that have been reviewed and have met all of the enterprise’s standards? You can’t go fast on autopilot without checks for security, compliance, and functional quality. Well, you can, but you’ll certainly regret it.
Even if your company relies on manual Pull Requests for code reviews, there are other checks that should be done before a change is deployed. A process that includes manual review is not really automation though, is it? Proper Deployment Automation replaces all manual reviews with automated scans by tools.
But do all changes require the same types of gates? The simple answer is no. The other is that it's complicated. Code changes, for example, require a set of checks, including:
Even if you construct a list of tests to run on each deployment, your automation tool must account for the types of changes made and run only the tests that make sense for those specific changes.
Changes to Role Based Access Rights may be a simple Metadata change that’s easy to deploy and forward through the pipeline, but they could easily open up huge holes in security. Automating that type of deployment without checking for any compliance violations is never a good idea. We suggest checking all your permission changes using a Security Compliance tool and a set of rules established by your compliance team. That way, you can move forward with peace of mind.
So—you’ve identified the checks and balances associated with each type of change, but should you apply them at every stage of the testing pipeline? It’s a good question. After all, this may seem like overkill and could unnecessarily slow down the process. The truth is that automation steps should be appropriate for each stage of the development pipeline.
While Static Code Analysis makes sense when merging code to Integration, once the code passes, testing will be redundant. Therefore, functional testing of a new feature and smoke testing for the app makes sense at the Integration stage, but full regression testing makes more sense in the test environment after several individual user stories have been merged. In fact, many organizations run full regressions after hours to conserve costs.
The timing of tests must take into account User Story Dependencies, as you can’t trigger a test until all solution pieces are in place. These User Stories could be in different pipelines and developed on different stacks.
For example, a new Salesforce feature that relies on a new API from an external service provider and a Mulesoft integration update cannot possibly pass its test until all of the pieces have been released into the same stage of development. Remember: some pipelines might have a different number of environments, so your dependency analysis should be aware of how stages align across pipelines.
Merge Conflicts are a big part of Continuous Integration and may require manual resolution, but these same steps must be followed in later stages as well. A good DevOps automation tool will provide an automated system to perform these merge steps in all subsequent pipeline environments based on the developer's manual conflict resolution.
While creating automation rules as scripts may be tempting, this may not be practical in the real world. Code-related tools can be maintained by coders, but Compliance and Security rules may be developed and maintained by non-coders. Wherever possible, automation should be created as declarative policies enforced by a DevOps Orchestration engine.
Many traditional tools for Salesforce Deployment Automation rely on scripts to determine what checks are performed, but scripts are typically written by developers who have the ability to bypass them if they want to. Don’t get us wrong; we’re not saying developers are untrustworthy. However, in the heat of the moment, when a perfectly good piece of code needs to be released in a hurry, developers may be tempted to take shortcuts when deployments are failing because of some pesky little warning about an out-of-date open source library. They can update the library in the next sprint, right? For them, it’s just more technical debt.
Compliance Audits are a normal part of business in regulated industries. Auditors must be able to verify that all of the rules have been followed concerning a given change. Clear logs must be kept, showing which rules were applicable to a given change, that all tests were conducted, and that the tests passed. These logs should be easily discoverable from a given change and verified by someone who may not be technical. The best way to ensure this is to log the tests and results on the User Story itself, which contains the description of the business requirements and the high-level description of the process change.
While the ideal goal is to automate the entire process through to production, the reality is that many business budgets and processes may not support 100% automation.
Even so, pull request reviews and other manual approval steps in the Build Phase could still be required. Salesforce automated testing can help ensure that these reviews are completed in a timely manner, while reminders should be generated and escalated as needed to keep the work flowing.
Change Control Boards (CCB) in highly regulated companies often require manual approvals. While Automation Tools can’t provide the approval directly, a good tool will support the automation of a release based on a trigger from the IT Management system that governs the process.
In companies that conduct UAT testing and manual feature testing, Continuous Delivery (CD) systems must be able to generate releases based on the features and user stories that have been approved. This means that the branching strategy used in the Version Control system must make it easy to release the stories that have been approved. Merging changes into a release branch makes it challenging to do this since the changes associated with the rejected stories must be removed from the release and likely run through a full regression test to validate the work. We suggest using a CD tool that is able to synthesize a release based on the stories that have been approved at any stage of the pipeline.
Last but certainly not least is the timing of the production release. Consumers are used to small changes appearing in their favorite apps, but enterprise knowledge workers are not. Sales professionals in the last week of the quarter will not have the time or patience to learn how to use a new process, so even though this article has focussed on automation, that does not mean that Continuous Delivery to production will make sense for all apps in all companies.
In fact, in a recent poll result published in the Forrester State of DevOps report for 2023, the most common release frequency for enterprises across their organization is twice a year (21%), once a quarter (20%), and once a month (18%) respectively. On top of that, more than 84% of organizations surveyed release once a month or longer. Of course, some of this can be attributed to inefficient processes, but the likely reason is the organization’s ability to absorb change into the business processes.
For the average IT department, Deployment Automation will not necessarily increase their release rate into production, but it will improve the release frequency of deployments in the development pipeline and ensure a smooth release into production when the time comes. The efficiency gains will reduce the cost of development and likely improve the quality of those releases as well.
Never forget that DevOps is not only about the tools you can use; your people and processes also have a huge role to play.
At its heart, Deployment Automation requires a candid examination of your process and a commitment to the incremental change required to embrace automation's efficiencies. Adequate training for your team and a little reassurance that automation is not about replacing their position but increasing their “Flow Time” to make them more productive can make a world of difference. With that taken care of, all that’s left is choosing the right tools to support your adopted processes. That’s where a Salesforce DevOps platform such as Copado comes in.
The result? More time to focus on other areas of business.
.svg){kind=small}
.svg)
.webp)
.webp)
