Part I: Challenges and Limitations
It’s almost impossible to refer to CRM (Customer Relationship Management), the foundation of business, without bringing up Salesforce, the leading low-code SaaS CRM provider. Customers can leverage its out-of-the-box functions to help their enterprise achieve seamless business flow like marketing, prospect and customer tracking, sales management, commercial applications etc. In addition, customers can also personalize unified business requirements through more in-depth customization.
So what is the development and deployment process for such a low-code product? What are the common problems encountered during its development and deployment process? Are DevOps tools such as CI/CD pipeline applicable to Salesforce as well? In the first part of this article, we’ll focus on its challenges of limitations.
The pain points for development and deployment in Salesforce
In the Salesforce development ecosystem, there are two mainstream development models of Salesforce: the Org-Based and Package-Based development models.
Figure 1: Metadata in org-based model
When using the Org-Based development model, different types of sandboxes are created from production and activities such as development, testing, delivery, release and training then performed in the different sandboxes. The essence of this development model is to enable the flow of metadata from sandbox to production org. In this model, metadata files are organized by type, which can lead to mixed metadata of different functions that are hard to distinguish.
Figure 2: Metadata in package-based model
The Package-Based development model is a more modern development model that ensures each delivery is a small, independent and loosely coupled package by organizing the relevant metadata files into packages. Deployment activities are accomplished by promoting and installing packages to different environments. Compared with the Org-based model, introducing packages helps to manage metadata files in a more organized and modular way.
The Org-Based development model is one of the most widely used development models today. Change Set is the de-facto official deployment tool in Org-Based development projects, whose drawbacks bring many limitations to the work of implementation and deployment.
Before we get started on understanding the specific pain points that are being widely discussed, let’s first take a quick look at what Change Set is. Change Set is Salesforce's native deployment tool for administrators & developers, which allows users to build artifacts by manually adding changed metadata, and then establishing deployment connections to synchronize the metadata between a source Org and a target Org.
Figure 3: Change Set deployment
This type of manual deployment is very friendly for small changes because of the user-friendly interface and easy manual operations, however, with more complex scenarios, it may lead to the following problems:
Inefficient deployment - Since Change Set relies heavily on manual operations, deploying a large number of components, either to create a new Change Set correctly or just adjust the contents of an existing Change Set, is a time-consuming task.
High Error Rate - It is easy to miss components when creating a Change Set, so it requires a lot of effort to manage the dependencies between components in order to create a Change Set accurately.
One-time deployment - When deploying to different environments (QA, UAT, Prod), you need to repeatedly create Change Sets from scratch to synchronize metadata across different environments.
Hard to Rollback - Change Set can only add or modify components to the target environment, and cannot delete existing components. Since there is no version control function, it is quite difficult to compare the functional differences among different environments.
While these are some difficulties in the Change Set deployment approach, we have also observed in a number of client projects that Salesforce development teams are faced with some additional challenges such as team collaboration, engineering practices and release approach etc. due to the limitations of the Org-Based development model itself.
Code Override - With the Org-Based model, production Org is the single source of truth (SSOT). Unlike VCS, where conflicts can be easily identified and resolved, the Org-Based model relies more on agreement and timely communication between developers to avoid code being overwritten in a collaborative development scenario.
Code Quality Management - As a multi-tenant platform, Salesforce has different coding constraints compared to traditional development platforms. All tenants on Salesforce share the hardware infrastructure, so Salesforce strictly limits the resources that each user can use during the execution of a single transaction. Compliance of daily development commits with Salesforce's coding best practices is often the key factor in determining a team's code quality. However, in this development model, it is difficult for the team to introduce more third-party toolsets to help automate code analysis, code quality verification etc. So in this case, guaranteeing high code quality is hard.
Manual Testing - Under this development model, end-to-end testing relies more on manual testing. Both functional testing and regression testing are time-consuming and labor-intensive.
Sandbox Management - Salesforce gives us different kinds of sandbox environments. The data policies and refresh cycles are different. With the increasing complexity of business requirements, ensuring the consistency of data and metadata among different environments becomes tricky and breaks the testing and deployment process.
Summary
Although the SaaS service of Salesforce benefits the customers as it requires less effort on infrastructure set up and operations, there are various pain points when it comes to development and team collaboration, which all result in a longer development cycle time and fragile code. A sure-fire way to mitigate the problems is DevOps, the benefits of which are well proved in other platforms and tech stacks.
The second part of this article will give you a detailed look at how to use DevOps thinking to empower improvements in the Salesforce development experience.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
