Tag Archives: Version control

A vector illustration with white ones and zeros and the word "rollback" in red signifying a rollback strategy in Salesforce

Salesforce Rollback Strategy: A Primer

A robust rollback strategy in Salesforce safeguards your change management process against bugs and errors in releases. In this blog, we discuss exactly what a rollback plan is, when you should use one, and how to implement it.

What Is a Rollback Strategy in Salesforce?

A vector illustration with white ones and zeros and the word "rollback" in red signifying a rollback strategy in Salesforce

A high-level definition of a Salesforce roll back strategy is a set of procedures you put in place to revert changes to your production environment. These procedures restore your Salesforce org to the stable state it was in before your previous deployment.

What Is the Purpose of Rollback?

The purpose of rollback is to minimize the impact of any bugs or issues that arise after deploying new changes to production. Because it acts as a kind of safety net, developers often call it the “oops button.”

Why Is a Rollback Strategy Important?

When you include a rollback strategy in your deployment process as a matter of course, you ensure you can quickly and easily deal with any issues without your end users being affected.

What Should Be in a Rollback Plan?

Your rollback strategy should encompass a carefully constructed, written, and tested plan that outlines all the steps you need to perform to revert production to a stable state. It should also define the part each team member plays in the process. In addition, it should include the checks you have to run and how to respond in the event of a failure situation.

When Should Rollback Be Used?

Use a roll back to restore stability to production when serious issues occur during a deployment, such as bugs or errors you can’t resolve in a short amount of time. 

You should also use one when new changes are causing complications that have a negative impact on your Salesforce instance’s performance. By performing a rollback to restore your production org to the state it was in before the changes, you can restore stability for your end users. They can go about their daily business, while you can work on a fix for the issue in an isolated environment.

How Do You Perform a Rollback Operation in Salesforce?

Now you know what a rollback plan is and when you need one, you’re probably wondering, “How do I rollback changes in Salesforce?” 

You can roll back changes using Salesforce tools, but this is quite complicated, as you can see from the steps below. You can also use Prodly to quickly and easily rollback a deployment.

How to Rollback a Deployment in Salesforce

To rollback a deployment in Salesforce, perform the following steps.

Stop the Deployment

If any issues arise during the deployment of a change, stop it immediately to prevent further damage to your Salesforce instance.

Inform Stakeholders About the Rollback

Communicate to everyone on your team, as well as all users and other stakeholders, that you’ve decided to perform a rollback and why.

Define the Scope of the Rollback

Determine which components have been affected by the deployment and need to be rolled back. Use this analysis to plan the steps you need to take to restore your production org to its previous state.

How to Rollback a Metadata Deployment

First, we’re going to look at how to rollback metadata changes. Let’s say you have three versions of a Flow, and the most recent version, version 3, is causing problems. You can deactivate version 3, reactivate the previous version (version 2), and deploy version 3 to a sandbox so you can fix it. You’ll have to perform a similar step for each metadata component that’s affected.

An image of deactivating a Flow in Salesforce to illustrate a rollback of metadata in Salesforce
How to Rollback a Config Data Deployment

Performing a rollback of config data (for example, if you’ve made changes to Salesforce CPQ) is more complex. First, check that you made a backup before you deployed the record updates. Then use Data Loader to revert the updates with that backup. If you inserted new records, identify them using a query or a Salesforce report, and delete them from production.

Check and Test

After you’ve restored your production org to the stable version, ensure that it’s fully functional. This might involve reconfiguring settings, reimporting data, or updating configurations.

Test thoroughly to make sure all components are working as expected and that there are no unexpected problems.

Communicate With Stakeholders

Inform your team, as well as all users and other stakeholders, that the rollback has been successful. You should also make them aware of any changes to production that will impact their workflows.

Roll Back a Salesforce Deployment in 5 Steps With Prodly DevOps

Prodly DevOps integrates with various version control systems, including GitHub. Because of this, it lets you easily perform a rollback in five simple steps:

  1. Navigate to the appropriate repository in GitHub and select the branch you deployed the changes from.
  2. Click on “Commit History” and select the pull request you want to roll back in the commits list.
  3. Click “Revert” at the bottom of the pull request and select the revert branch GitHub creates.
  4. Merge the new pull request GitHub creates into the branch you originally deployed the changes from.
  5. Deploy the restored changes from your branch to your Salesforce org.

Then all you have to do is log into Salesforce and confirm that your changes are successfully rolled back.

Conclusion

To ensure the continuity of your Salesforce instance, it’s critical to have a well-defined rollback strategy. By consistently making sure you have one for every significant deployment, you can minimize the impact of issues on your production environment and maintain the trust of your users.

FAQs

What’s the difference between a rollback and a roll forward deployment?

When you perform a rollback, you revert your production environment to a previous state of stability—but then it doesn’t have the new features. With a roll forward deployment, you add additional changes that fix the issue while at the same time keeping the new features live. 

How often should I make a rollback strategy?

It’s advisable to have a tested rollback strategy in place for every significant deployment you make.

The enter key on a computer keyboard with the word oops on it representing version control for Salesforce CPQ configuration.

Benefits of Version Control for Salesforce CPQ

In this blog, we discuss the benefits of version control for Salesforce CPQ configuration, such as the fact that it lets you roll back to prior states with laser precision. In addition, it helps you meet SOX requirements, collaborate more effectively, and implement an agile release management process.

Easily Roll Back to Prior States With Laser Precision

With a version control system (or “oops button,” as we like to call it), you can quickly and easily roll back a specific change or many changes to a mission-critical system like Salesforce CPQ.

The enter key on a computer keyboard with the word oops on it representing version control for Salesforce CPQ configuration.

Let’s say you’re having issues with a Price Rule. Your production org may have dozens or even hundreds of Price Rules, so figuring out which one contains the bug will take time. Do you really want to do that in production… while the downtime prevents sales reps from closing opportunities?

With a version control system (VCS), you have a running log of every change to your Salesforce CPQ configuration. This log is the source of truth for your CPQ implementation, which is why it’s called source code. In the case of CPQ, this includes configuration data

So if there’s an issue, you simply hit the “oops button” and roll back the change to the previous version of the code. Now you’ve restored the system for users, you can do your debugging in a sandbox where you can’t do any damage.

Meet SOX Compliance Requirements

The Sarbanes-Oxley Act of 2002 is designed to help protect investors from fraudulent financial reporting by public corporations. For companies using Salesforce CPQ, this means they have to comply with two main requirements:

  1. They must maintain a complete audit trail of changes to all financial data, including pricing and products.
  2. They must maintain separation of duties.

Failing to meet SOX regulations can result in steep financial penalties, as well as prison sentences. For example, accountants and auditors who are not in compliance can face up to a decade behind bars. 

Recently, auditors have started to catch on that record data falls within the scope of compliance requirements. Record data provides configuration for Salesforce CPQ.

Version control for Salesforce CPQ provides an immutable record of what changes were made, by whom, and who checked them in. And you need a version control system. Why? Because even if you haven’t heard anything from the auditors, you’re breaking the law if you’re not SOX compliant. That’s why it’s advisable to get ahead of the situation and implement version control (VC) as soon as possible.

Collaborate More Effectively With Version Control for Salesforce CPQ

A version control tool for Salesforce CPQ lets you collaborate more efficiently and effectively with your team. Everybody should configure their specific changes in their own environments. Once they’re done, they should check in their work to the source. As a result, every team member can work on their part of the project without fear of wiping out each other’s work. 

In addition, with a version control system (VCS) for Salesforce CPQ, you can thoroughly review all proposed changes before deploying them. This gives you the opportunity to identify conflicts and errors. If there are any, you can resolve them before they go into production.

Implement an Agile Release Management Process

Clearly, Salesforce CPQ version control effectively facilitates an agile release management process. It helps you reduce development time and time spent troubleshooting. As a result, you can deploy successful changes faster.

FAQs

What is version control?

Version control is a data management practice that’s also referred to as source control or revision control. It’s a critical tool for tracking changes to your Salesforce CPQ configuration data or record data as you move it through the release pipeline. This is especially true in an agile environment where you make changes quickly and dynamically. Learn more about version control.

What is a VCS and how does it work?

VCS stands for version control system. When you integrate Salesforce CPQ with a version control system, you can record and manage the changes you make to your configuration data. 

You check a file out of the VCS, update it with the changes you’ve made, and check it back in. If any of the changes you made don’t work during testing, you can refer back to the source configuration file to revert the configuration back to the earlier version. Learn more about version control systems. 

The importance of version control in Salesforce

Versioning and Backup in Salesforce

Versioning tracks the flow of changes in your code, metadata, or configuration data. It’s important because it provides an auditable history of changes. You can refer to this history if you need to roll back to a previous version due to an issue. You can also refer to it for SOX compliance purposes. Versioning also facilitates collaboration.

Backup is the practice of routinely taking a snapshot of your Salesforce org. Its value is that you can use it to restore and recover your records in the event of a disaster.

In this blog, we’ll take a closer look at the definitions of versioning and backup. We’ll examine the importance of backup and source control in Salesforce DevOps. And we’ll describe how to use each of these methods to accelerate development in Salesforce with less risk.

The importance of version control in Salesforce

What Is Backup?

A backup is a copy of a portion or all your metadata, configuration data, and transactional data from your production org. You store this backup outside of your Salesforce production org. It allows you to recover and restore your production org to the most recent snapshot if you suffer data loss or corruption.

Data loss can occur due to a serious technical issue, an employee mistake, a bad actor, or even a cyberattack. As such, backup is a critical aspect of data management and data security.

Backing Up Data and Metadata

You need to have a defined backup strategy for both your data and metadata.

Back Up Your Data

To backup your data, you can use:

• Data Export App: Manual or scheduled exports of your data using the UI
• Data Loader: Manual, on-demand exports of your data using the API
• Report Export: Manual, on-demand exports of your data using reports

Many companies back up their data to external cloud storage outside of Salesforce, as well as to hard drives.

Back Up Your Metadata

To backup your metadata, you can use:

• Change sets: Copy metadata from production to a sandbox or Developer environment.
• Sandbox refresh: When you refresh a sandbox, the metadata is automatically copied over.
• Force.com Migration tool: Java/Ant-based command-line utility for moving metadata between a local directory and a salesforce org
Package Manager: Create an unmanaged package of your metadata to save in Salesforce.

Salesforce Backup and Restore offers backup, recover, and restore for Salesforce. It lets you create backup policies that automatically generate backups. In addition, you can use it to restore data in just a few clicks.

There are also various third party backup solutions available on the AppExchange.

Why Should I Back Up My Salesforce Data?

It’s essential to routinely back up your Salesforce data as a part of your overall data management and security model. There are so many things that can cause data corruption or loss. Think of a bug, technical glitch, virus, or intentional data theft by a bad actor. Backup mitigates the risk.

If part or all of your org is wiped out, your users can’t do their jobs anymore. You lose the record of what you’ve sold and delivered, as well as what the next steps are with a customer. Worse: Your customers would be in for a terrible customer experience. This in turn has a whole host of consequences, including financial, reputational, and even legal repercussions.

When you have your data backed up, you can easily restore it and get back to business as usual. A backup won’t protect you from data corruption or data loss, but it makes it easier to recover from a catastrophic incident.

What Is Versioning?

Versioning is also referred to as version control or source control. It provides a single source of truth, as well as automation, that lets teams make changes to Salesforce faster and more reliably. It also improves collaboration across the team.

What Does Versioning Involve?

Versioning involves maintaining an accurate history of all changes made to how the production org is set up in a shared repository. It automates many of the tasks associated with maintaining an auditable history of the org’s changes.

With this detailed change history, you can easily pinpoint and undo any change when you need to roll back a change in Salesforce.

Backup reverts the entire org to the previous snapshot. In contrast, versioning offers the targeted rollback of specific changes made during development.

Source Control for Low-Code Apps

Pro-code developers have used version control systems (VCS) for decades. However, because Salesforce is a low-code application, source control has only recently become available to low-code admins.

Third-Party Tools for Versioning in Salesforce

There are several third-party tools that provide versioning for Salesforce, like Prodly DevOps. In addition, Salesforce DevOps Center integrates with GitHub, which provides a powerful source repository.

Versioning involves:

Maintaining a Shared Repository

The VCS has to maintain a shared repository for everyone on the team of all project code, metadata, and configuration data on a server. This shared repository must have a form of automatic backup.

Tracking Changes per File

The VCS must track changes per file (such as a metadata component or a Price Rule) that you commit to the repository. This allows you to review a file’s entire history. If you commit multiple files as a bundle, you can see the changes to them, as well. Additionally, it also makes it easier to determine failures from a specific change. Plus, you can easily revert one file or a bundle of files to the previous state… or any state before that.

Storing the Code or Data Somewhere Changes Can Be Detected

The code, metadata, or configuration data must be stored in a place where a build system like Salesforce or VS Code can detect changes to the repository. The build system then automatically triggers a build and an immediate integration test.   

Managing Conflicts and Overwrites     

The version control system must manage conflicts and overwrites among multiple users. The source control system can do this by leveraging tools that automatically merge changes and detect conflicts. It may also require individual developers to lock the files they’re working on so only they can access them.

Sending Automatic Notifications

The VCS must send automatic notifications to developers when specific files change or when they need to manually resolve merge conflicts.

Why Enable Versioning in a Salesforce Release Pipeline?

Managing Salesforce changes in a source repository is the foundation of automating your release pipeline. To enable true CI/CD, Salesforce or VS Code need to know instantaneously when you’re making changes to the repository. Versioning instantly updates the source code when you make a change. This offers five distinct benefits.

Change History

It maintains a change history, which allows you to restore components or parts of components to before the last change with laser precision.

Collaboration

Versioning facilitates collaboration, because multiple people can seamlessly work on the code, metadata, or configuration data at the same time. They won’t overwrite each other’s changes or introduce changes that could break any functionality.

Change History

It provides an accurate history of the who, what, when, and why of all changes that were made. This is critical in apps like Salesforce CPQ or B2B Commerce that require meticulous change tracking for SOX compliance purposes. The detailed history of changes makes the source repository auditable over time.

Because you add notes when you commit changes, you can link the why of a change to a specific user story.

Troubleshooting

Versioning enables troubleshooting as early as possible in the release pipeline, which helps minimize costs. Because versioning facilitates continuous integration, every change you make triggers an automatic build. It also runs automated tests. If the change causes any kind of conflict or issue, you’ll know about it in just a couple of minutes.

Should I Use Version Control or Backup in Low-Code Salesforce Apps?

Version control and backups are clearly not the same thing. Version control helps accelerate your development cycle, and backups protect you from the consequences of data loss or corruption.

In Salesforce, each method plays an important role:

• To safeguard your transactional Salesforce data such as Accounts, Contacts, and Opportunities, back up your data using either data exports or a data backup solution.
• To accelerate development and releases, use source control to manage and version code, metadata, and configuration data.

If you want to adhere to DevOps best practices, you can’t use a backup solution for source control in Salesforce. Why? It doesn’t provide the automation you need for continuous integration. On top of that, a backup solution also doesn’t provide the granular change tracking you need for versioning and compliance.

Continuous Source Control Software for Salesforce

A comprehensive DevOps solution like Prodly DevOps offers the ability to integrate your release pipeline with GitHub, Bitbucket, and Azure. This provides you with meticulous change tracking and version control for metadata and configuration data in Salesforce. It enables fast and easy rollbacks if needed. Plus, it ensures SOX compliance. It also facilitates streamlined collaboration between your team members.

To learn more about Prodly DevOps, request a personalized demo.

Salesforce admin using version control.

Version Control: What Salesforce Admins Need to Know

Version control is a critical aspect of software development, and it’s becoming increasingly important in Salesforce change management. In this blog, we discuss what version control is and how it can benefit Salesforce admins.

What Is Version Control?

Version control, sometimes called source control, involves tracking and managing changes to software code to ensure developers are always working on the latest version. 

If you only have one software developer writing code, it’s easy for them to keep track of the changes they’re making and how they impact the existing code. However, when multiple developers are working on different parts of the code, it requires much more effort and communication to keep the changes straight. 

A version control system or VCS is a tool that makes tracking and managing changes to the code easier for teams. 

Teams maintaining Salesforce encounter the same challenges as software developers. There are lots of people working on different parts of the Salesforce instance. Some are pro-code developers working in Apex, while others are admins and citizen developers. 

With all these different people working in the same environment, sometimes work is lost or overwritten, and it can be difficult to fix mistakes. 

Clearly, for admins following an agile release management methodology, version control is essential. 

Salesforce admin using version control.

How Can Admins Benefit from Version Control?

The most important advantage to using a VCS is that it becomes the source of truth—instead of the production org. 

This eliminates questions about which version is correct and provides several additional benefits for admins. 

Identify Conflicts as They Occur

When you’re working with multiple versions of your project, a VCS lets you make changes without worrying you’ll overwrite work another member of your team is doing. By enabling source control, you remove the anxiety of creating conflict when you implement changes. 

Track the Revision History of Changes Over Time

Sometimes, when you’re making changes, you need to refer back to a specific change you scrapped previously. A version control system stores a history of all changes made to the code, so you can easily look them up.

With Prodly, you can effectively “move backward in time.” Then you can pluck out the configurations you need and reconfigure your changes as simply as pointing and clicking. 

Work in a Truly Agile Environment

Agile release methodology is based on close collaboration and continuous improvement that you achieve by means of tight feedback cycles. For this methodology to be effective, both developers and admins need to work from the same source code and follow the same process for introducing change. 

To achieve this collaborative efficiency, you must reconfigure your workflow. It should be easy for pro-code developers to follow—plus, it should be easily consumable for admins and other no-code team members. 

Prodly Makes Version Control Simple

Prodly DevOps is designed to work in conjunction with your Salesforce deployment system, so you don’t have to load up on multiple tools to get the benefits of version control. If you’re an admin, you can simply point and click to complete versioning tasks—as well as version both your data and code. 

Request a personalized demo to learn more about implementing Prodly for your team!

Version control in Salesforce

What Is Version Control and What Are Its Benefits?

A version control system (VCS) tracks and manages the changes you make to your data and configuration data. It’s critical to managing changes in low-code Salesforce apps that use complex configuration data, like Salesforce CPQ and Field Service Lightning. 

A VCS offers many benefits, including faster iterations and configurations, improved collaboration within teams, and enhanced compliance. 

Version control in Salesforce

What Is Version Control?

Ever wish you could roll back changes you just made to your production org in error? How about being able to track the revision history of your changes over time?

Version control (also known as revision control or source control) is a methodology that resolves data control and management scenarios like these.

A VCS tracks and manages the changes you make to your data. In Salesforce apps that use configuration data, tracking changes as you move the data from Developer sandbox to QA to UAT to production is paramount. 

Especially in DevOps, where your changes occur fluidly, dynamically, and rapidly, version control is an essential component of configuration data management. That’s why it’s increasingly becoming a necessary element of the release management process.

The Benefits of Prodly With Version Control

Prodly with version control makes agile development a reality for complex, low-code Salesforce apps. Unlike other version control offerings for Salesforce, Prodly manages your configuration data, which makes it perfect for Salesforce CPQ, FSL, Billing, and B2B Commerce.

Prodly version control combines the power of Salesforce orgs and VCS branches. Using Prodly version control as your single source of truth has the following benefits when compared to traditional in-org development:

  1. You can iterate and configure faster in a truly agile environment.
  2. It improves collaboration within and amongst teams.
  3. You can ship complex configuration features faster.
  4. You can identify conflicts head on.
  5. It provides a full change history and audit trail.
  6. It allows you to maintain SOX compliance.
  7. You can easily roll data back to prior states.

How Does Version Control Work in Salesforce?

Version control in Salesforce works like this:

The initial master data commit retrieves your configuration data from your Salesforce production org and stores it in the VCS. At that point, the data in the VCS becomes your single source of truth. Going forward, you initiate all changes to data in your production org through the VCS.

A version in the VCS is a snapshot of your data at a given time. You check data out of the VCS, update it, and check it back in, creating a new version against which further changes are made. Then, if needed in the future, you can roll back your data to any version.

The VCS records all the changes you make so you can easily roll back to an earlier version if necessary due to a bug. At the same time, this change tracking creates an audit trail you can use for compliance purposes.

Does the VCS Replace My Deployment System?

You might be wondering whether the VCS replaces your deployment system. The short answer is no, it does not. 

The VCS works in conjunction with your deployment system through a concept called branching. A branch is a snapshot of your data created in the VCS and then deployed to a separate Salesforce sandbox or development org. 

Similar to how you likely work now, you develop your new features in the separate org to protect the data in your production org. When you’re ready, you check the changes back into the VCS branch, merge the branch back into the master, and deploy the changes to your production org.

To learn more about Prodly, request a demo.