Introduction to Version Control

Version control (also known as source control) is a data management methodology. A version control system (VCS) tracks and manages the changes you make to your data. For complex, low-code Salesforce apps, such as Salesforce CPQ and Salesforce Field Service, tracking the changes to your reference data as you move the data from developer sandbox to QA to UAT to production is critical. Especially in an agile development world where your changes are occurring fluidly, dynamically, and rapidly, version control is an essential component of reference data management and is increasingly becoming a necessary element of the release management process.

Version control has been a staple of software development and documentation environments for decades. You check a file out of the VCS, update it, and check it back in. Declarative, low-code apps replace the need for coding with reference data, so implementing a VCS in a low-code app environment is a natural way for teams using declarative, low-code applications to enhance business agility.

Benefits of using Version Control

By integrating a Version Control System (VCS) with your Prodly release process, you unlock a powerful set of capabilities that enhance safety, speed, and collaboration. Unlike other Salesforce version control offerings that focus on metadata, Prodly enables true agile release change management for your complex reference data. The key benefits include:

• Full Change History and Audit Trail The integration provides a complete and immutable version history of every single change made to your data. This allows you to deploy reference data between Salesforce environments in a fully trackable way, which is essential for maintaining SOX compliance and providing a clear audit trail for every modification.
• Enhanced Collaboration and Conflict Prevention Version control empowers teams to collaborate more effectively in a true agile environment. It provides a mechanism to review proposed data changes before deployment, similar to a code pull request. This process helps identify potential conflicts early and prevents team members from accidentally overwriting each other’s work.
• Increased Agility and Faster Releases By providing a clear and streamlined change promotion and review process, teams can iterate on complex configurations and ship new features faster. This transforms your reference data management from a potential bottleneck into a component of business agility, allowing you to react quickly to changing requirements.
• Reliable Rollbacks and Data Recovery Each commit to the VCS acts as a snapshot of your reference data at a given moment in time. This powerful feature gives you the ability to easily roll back or revert your data to a previous known state, providing a critical safety net if a deployment introduces unintended errors.
• Powerful Data Synchronization The connection to a VCS allows you to reliably synchronize data across your environments. The process manages not only updates and inserts but also the deletion of records, ensuring that your environments can be perfectly aligned with the state of a repository branch.

Choosing Your Version Control Strategy

Prodly supports two distinct strategies for integrating a Version Control System (VCS) into your release process. Your choice of strategy will depend on your team's existing workflow, your compliance requirements, and whether you want your Git repository or your Salesforce environments to be the primary source of truth for your reference data.

Read the descriptions below to determine which model is the right fit for your team.

Strategy A: Source-Driven Development (Version Control as the Source of Truth)

This strategy represents a true Git-based workflow where your VCS repository becomes the central source of truth for all versioned reference data. During the initial setup for this model, Prodly retrieves the reference data from your Salesforce environment and stores the data in the VCS repository. From that point forward, the data in the VCS is considered the single source of truth.

In this model, you no longer deploy data directly from one environment to another. Instead, all changes are first saved to a VCS branch and then deployed from that branch to a destination environment. This ensures that every change is tracked, can be reviewed through pull requests, and is permanently stored in your Git history before it ever reaches another environment.

Typical Workflow:

1. Deploy data from a main branch in the VCS to a developer sandbox.
2. Make your changes to the reference data within the sandbox environment.
3. Save the changes from the sandbox back to its dedicated VCS branch.