If your company is forward-thinking and obsessed with digital transformation like many enterprises today, then it’s probably heavily invested in Salesforce. This is a platform that allows you to get the best out of your investment with customizations that go beyond the ordinary limits. However, all this freedom means you must be prepared to install ongoing adjustments to your business process’ tools to take care of your security. DevSecOps comes in at the intersection of DevOps and Security, and if properly configured and implemented, has the ultimate power to safeguard all your Salesforce configurations and customizations.
Whenever there’s a severe security breach, it shows us how useless technology can be if not correctly configured. It’s up to you to ensure that all your technology investments are set up correctly, especially for customer-facing systems like Salesforce.
So, let’s get to the finer details and start with the big question of the day…
Industry leaders, Copado, recommend using User Stories to manage change management releases so that you also get to know the “why” behind changes instead of only getting the ‘who,’ ‘what’ and ‘when’ with git Repos.
#Quality Gates
If you want to guarantee your Salesforce investment will last and yield the right ROI, then you must protect all the functional enhancements you have from day one. Most organizations have had to devote thousands of person-hours to ensure the existing implementations are working correctly, only for such to be ruined with just a single unmonitored, incorrect change.
With quality gates in place, you are safeguarding the perfect operation of your current new features and protecting those made earlier. In most circles, functional testing, the quality aspect that guarantees the perfect working on new features, has had to be used with tools such as Fusion, Selenium, and Provar having to be used.
One way to ensure you are covered all the way through is to employ source code quality standards so that if the engineer who began the journey with you leaves, the next engineer will simply scan the code and identify with it quickly because it was written following a set standard.
Another technique or approach that needs to be put in place is Static code analysis, which will help you unearth bad practice within the code that would otherwise hamper its performance.
As an organization, you can invest in Unite tests to ensure code is working as expected. Apex Test Coverage is another way of ensuring everything works as expected.
What is DevSecOps?
Security has many parameters unique to each system, and for Salesforce, this is mostly managed through permission sets, profiles, and sharing rules. All these put together provide control over access to the service (which includes admin permissions and login) and access to data at the field, record, and object level. The organization of the security parameters in Salesforce is important, but does not provide the full extent of what it takes to protect your investment. Speaking of which, you also need to think about protecting your settings, source code, and data from being accidentally deleted or overwritten. Others argue about the possibility of recovery from incidences likely to arise from deletion or overwriting of data, source code, or settings. Still, the actual loss is the time it takes to restore the lost items. Let’s review five key elements paramount to your DevSecOps practice on Salesforce and how best to go about dealing with each.#Single Source of Truth (SSoT)
Unlike in other platforms where setting up a Single Source of Truth (SSoT) is straightforward, in Salesforce it requires serious thought. However, you can make changes both in Production and Sandbox environments in no time in Salesforce. In DevSecOps, this is critical because of the possibility of losing work. It’s easy to lose all the changes you’ve made in production or test with just one deployment. To secure your investment from this mess, it’s advisable to make changes in development environments and save them in a version control system like Git to lower your chances of overwriting the changes. This way, admin and developers have one source of truth for changes they may want to make.#Audit Trail
An audit trail proves that you made the right changes and that the wrong ones were never done. It’s all about compliance and security. With one single source of truth set up in a version control system, audit trail answers the critical questions around who made the change, when it was done, what changed, and why the change was made. With a Git repo as the single source of truth, you can capture all the changes to your code and settings, changes in configuration data, and more, which are useful in Salesforce applications like CPQ. Furthermore, the system for capturing changes in Salesforce is relatively advanced, with audit records readily available in Salesforce standard reports.
Industry leaders, Copado, recommend using User Stories to manage change management releases so that you also get to know the “why” behind changes instead of only getting the ‘who,’ ‘what’ and ‘when’ with git Repos.
In an enterprise environment, running apex tests and the functional test could take hours. Considering a continuous delivery scenario and changes hitting an environment several times an hour, it would only stall full tests as most full tests would not run to completion because of changes hitting every now and again resetting it to start anew.
The best way out in such scenarios is for companies to run tests scoped only to the individual changes and conduct environment-wide tests on schedule. In ideal situations, your DevOps tools should be able to identify the scope of impact and only conduct tests when required. This is a long-term goal, but the industry is heading here.
