.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
CI/CD
言語
.svg)
.svg)
Developing an effective and efficient Low Code Deployment process isn’t easy. In fact, most teams take months to settle on a method that works with the required productivity. High-security standards, clear timelines and widely accessible data sets are all part and parcel of a successful strategy, but what really is Low Code Deployment and how can your business squeeze every last drop out of it?
If you’ve ever asked this question, you’re in luck. Our blog delves deep into the intricacies of Low Code Deployment and how it can be streamlined. Let’s get to it.
To fully understand this topic, let’s dissect the title a bit and establish the basics of Low Code Deployment.
While most software utilizes coding languages such as Python and Java to create applications, Low Code systems use point-and-click configuration for a large portion of the app development. However, just because the user experience is different doesn't necessarily mean that Low Code apps lack underlying “source code”.
Low Code apps use Metadata (MD) to define the configuration, even though most developers make their changes through a UI instead of a code editor. Under the hood of SaaS Platforms, this MD lives in a database, but externally the configuration can be represented as XML or JSON. XML is perfect for machines to read, but JSON is more accessible for humans. These are just two ways of representing the same information.
Deployment is a DevOps term that refers to delivering a software application or update from the development environment to the production environment, therefore making it available for the intended users. This encompasses a range of distinct elements, including transferring the code, data, and configurations from a controlled development or staging environment to a live production environment where the software can be accessed and used for its designed purpose.
With that in mind, the straightforward definition of Low Code Deployment is the deployment of MD from one environment in a pipeline to another. As we’ll see, it doesn’t necessarily always derive from a lower environment like Dev to a higher environment like Prod. Most Low Code Applications contain at least a small amount of Code, as well as configuration data. So—while this article focuses on Metadata, it’s worth bearing in mind that Deployments tend to present a little more complexity in practice.
Metadata in Salesforce is managed through the Metadata API (MDAPI), Tooling API, and SFDX. Two formats are now used for MD: Metadata Format and Source Format.
Metadata Format is the traditional format for deploying and retrieving MD components from Salesforce orgs. The second is called Source Format, which is designed to be more compatible with version control systems and to facilitate continuous integration and continuous delivery (CI/CD) processes. While Metadata Format organizes the components in a few files that can grow very large, Source Format breaks up the configuration into many smaller files.
Source Format has multiple advantages. The obvious one is that small files deploy faster than big files—you don’t need us to tell you that! The second is that when multiple developers are working in the same platform area, Source Format makes it less likely that there will be a Merge Conflict. (See the discussion below for more on Merge Conflict.)
A crucial note: none of the MD formats and APIs employed by Salesforce are 100% complete. When using other SaaS platforms, their rate is often much, much worse. There are still hundreds of areas you can complete in the setup that are undeployable. We won’t go into the details here, but remember that Robotic Process Automation tools can still be used to automate the update and create a ‘virtual deployment’ even without API support. Our Copado Robotic Testing can do this straight out of the box.
Using Version Control for MD is just as important as it is for Code. With multiple environments in a typical DevOps pipeline, you should never consider Production as the one source of truth. All of your Work in Progress (WIP) still needs to be reflected in Production. That’s why deployments are required in the first place! You should never assume that the lower environments are the source of truth for WIP. Anyone who has requested a sandbox refresh without saving their work first can attest to that. If this happens, wave goodbye to Development!
Let’s get back to the essence of the article. Now that we’ve established the basics of Low Code Deployment, it’s time to outline what efficient and effective Low Code Deployment actually looks like.
In the early days of Salesforce, Admins working in a sandbox had to keep a list of changes and manually recreate them through the UI in Production. Thankfully, those days are long gone. Efficiency, in this case, refers to automation and the subsequent elimination of manual steps.
Yes, yes, and yes.
If you are just starting out with Low Code DevOps, it’s likely that you will have encountered Changesets. While Changesets may be convenient for deploying a small number of configuration changes, it doesn’t work with Version Control, won’t track the underlying reason that the changes were made in the first place, and isn’t repeatable to a higher level. You need to manually create the change set in each and every environment of the pipeline. One thing’s for sure: an effective DevOps Automation tool is now a prerequisite for efficient deployments.
Unless you are a Lone Ranger managing a Salesforce instance, you will have to deal with multiple admins making changes independently of each other. Small teams can work together in a single sandbox, but this becomes cumbersome when more than 3-5 people are in that same environment. Eventually, the day will come when one of your changes will be wiped out by someone unaware of what you’re working on. The result? An architecture where each admin and developer has their own sandbox and changes get deployed into a shared integration environment using a Version Control System (VCS).
Low Code platforms, like Salesforce, don’t offer a Version Control system out of the box. However, when people work in different environments, the need for it becomes evident as changes are not easily integrated.
To be clear, Version Control out of the box will only solve some of the problems you encounter. In fact, it might even pose new challenges. The conflict between your change and the other admin’s change still happens, but it occurs in a much more visible way at the time of deployment when your changes are merged together with the other Admin’s changes.
Settling this situation is called Merge Conflict Resolution, and software engineers deal with it all the time when they make changes to the same chunks of code. A proficient DevOps tool is able to surface the issue and help resolve the conflict in a way that works for both parties.
As a side note, traditional source code tools do a pretty lousy job of resolving Merge Conflicts in XML and JSON. To efficiently resolve these conflicts, the DevOps tool must understand the structure of the Metadata and intelligently piece the two changes together. Oh, and by the way, this doesn’t only happen once in the Integration Environment; the same Merge Conflict must be resolved in each and every stage of the pipeline. A tip-top DevOps tool will automate this merging process once it has been completed manually.
There are a few types of MDs that pose significant challenges throughout deployment. Complex structures like page layouts and user profiles are perfect examples.
In Salesforce, a page layout describes how a page looks, which fields are visible, what buttons the user sees, and, in general, everything you would typically use HTML for to specify a generic web page. While HTML and other web page frameworks describe the look and feel of the page, Salesforce needed to tie this back to the object and field structure of the database, as well as hooking up automations to buttons, calculating formula fields, and myriad other capabilities that would require a skilled front end coder.
The challenge is that some pages for objects, like Accounts and Contacts, are used in almost every business process. Therefore, the Sales Cloud admin, Service Cloud admin, and Marketing Cloud admin must constantly make minor tweaks to a page layout independently of one another.
Think about it. One admin might be ready to release their changes, while the others are still working on their own. If admins work in the same environment, they can’t deploy the new page layout until everyone is ready. Separating admins into their own sandbox will help, but what if one admin merges their changes into Integration and it gets stuck there? The outcome is far from ideal. Special care must be taken to integrate these layouts and deploy them efficiently.
Speaking of Profiles, the security settings associated with objects and fields are just as important as the objects and fields themselves. Low Code applications should carefully consider which users should have access to the new features and include the access rights for only those users. The topic of access controls, Profiles, and Permission sets is beyond the scope of this document, but an efficient deployment strategy depends on a well-designed set of User Personae and their associated Profiles and Permission Sets.
We do have one word of caution: Page Layouts are not a security tool. While a field may not be visible on the page, this won’t prevent the user from accessing information.
To achieve efficient Low Code Deployments, you also need to understand that a Salesforce release goes beyond MD. A typical production release will likely include changes relaying on data like CPQ changes. It will also typically require executing some apex scripts to perform changes unavailable in the MD API, and obviously, new user permissions will need to be assigned.
To make it even more complex, values like usernames, external server URLs, or named credentials change at every stage. Therefore, it is critical that your DevOps tool supports all of the above and enables the application of automatic variables through each deployment to avoid manual tasks or (even worse) pushing a change with the wrong configurations.
Deployments are not a one-way street. Unless you have a straightforward pipeline with one sandbox and one production org, you must move changes back through the pipeline to the other sandboxes. These are called Back Deployments and are the best way to keep your sandboxes in sync.
Why is this important? We refer back to our old friend, Merge Conflict. Over time, if changes only flow toward production, your admin sandboxes will begin to drift from each other. Production may have all of the changes, but your sandbox will not feature the changes made by different admins.
You might think a sandbox refresh would solve the problem, but as we mentioned previously, it would wipe out all of the Work in Progress. We have an entire article on the topic of Sandbox Refresh and Hygiene, so make sure to read that for more information. For now, the key takeaway is that efficient Low Code Deployments depend on keeping environments in sync. The best way to accomplish this is undoubtedly using Back Deployments.
You may have heard the phrase ‘A bad workman blames his tools’. In the case of developing efficient Low Code Deployments, that isn’t quite the case.
Effective deployment requires the use of constructive, functional and practical tools, as well as establishing a solid process of Merge Conflict resolution and Back Deployments and training your team on the process. With the proper process in place, changes will flow like water through the pipeline, and your new features will land in Production before you can say ‘Copado’.
.svg)
.svg)
.svg)