Overview 

Prodly offers two main uses for the VCS:

• For customers already familiar with org-to-org deployment, the easiest way to get started with version control is to use the VCS to take snapshots of your data at given intervals to track your changes. Then, if need be in the future, you can revert the changes.
• For the scenario where you always deploy all records in a specific set of objects (that is, you do not need the query filter to filter records), you can use version-control deployment to track and deploy your data without the need for data sets or deployment plans.

Through integration of industry-leading version control systems (VCS), Release provides true agile release change management, enabling admins to track reference data changes made within a Salesforce org and easily maintain versions of the data in the VCS. In the current release, Prodly integrates with Azure, Bitbucket, and GitHub, giving you the power of the their collaboration tools. A simple and intuitive visual user interface empowers you to work with version control in a declarative fashion so teams can develop a change-and-release management process that delivers business value faster.

Through integration with a VCS, you can:

• Deploy reference data between Salesforce orgs in a trackable way.
• Synchronize data through updates, inserts, and deletes.
• Review proposed data changes before deployment.
• View a complete version history of every single change.
• Roll back/revert changes to previous known states.

What is version control? 

Version control (also known as revision control or 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.

How do I use a VCS with my Salesforce reference data? 

To start, during VCS setup, Release retrieves the reference data from your Salesforce org and stores the data in the VCS. At that point, the data in the VCS becomes your single source of truth.

A version, or commit, in the VCS is a snapshot of your data at a given time. You capture snapshots of your data at certain points in the deployment flow, so if needed in the future, you can roll back your data to a previous version.

As mentioned above, the current release offers two main uses for the VCS:

Version-Control Deployment	Org-to-Org Deployment
Deployment data passes through the VCS in both directions to track the history of the data’s movement. In this example, you deploy data from the VCS to a scratch org or sandbox, update the data in Salesforce as you do now, then save the data back to the VCS, creating a new version.	Deployment goes directly from org to org. In this simplified example, you deploy some data from production into a sandbox, modify the data in the sandbox, and then update production. Additionally, you can save snapshots of your data in the VCS at any point in time for versioning or backup.

What are the benefits? 

Release makes agile development a reality for complex, low-code Salesforce apps. Unlike other version control offerings for Salesforce that focus on metadata, Release version-control deployment manages your reference data. Release combines the power of Salesforce orgs and version control systems, giving you the following benefits, compared to traditional org-to-org development:

• Iterate and configure faster in a true agile environment.
• Collaborate within and among teams.
• Ship complex configuration features faster.
• Identify conflicts head by reviewing proposed data changes before deployment. Tell Me More
• Provide full change history and audit trail. Tell Me More
• Maintain SOX compliance.
• Roll data back to prior states. Tell Me More
• Prevent team members from overwriting each other’s work.
• Streamline change promotion and the change review approval process. Tell Me More

Version Control Deployment

Overview 

Version-control deployment brings true agile release change management to reference data deployment.

• Move the configuration information in the data, as well as the data records themselves, with a unique, intuitive user interface.
• Use the VCS to track the changes to your reference data.
• Optionally, roll back those changes when needed.

Version-Control Deployment Building Blocks 

Salesforce orgs, VCS repository branches, and the management board are the building blocks of version-control deployment.

Version control systems store data in repositories. Release uses a single VCS repository to track and manage changes you make to the data in all the orgs you place under version control. Repositories contain branches. When you initially place your data (typically, but not necessarily, your production org data) under version control, Release copies the data from the org to a branch in the repository and that branch data becomes the new source of truth.

At that point, the org becomes a Release managed org and a card for it appears in the Release tab. For each additional org you place under version control, Release creates a managed org card on the board and a separate branch in the repository.

To maintain tracking integrity from that moment forward, you don’t directly edit data in your production org. Instead, your data always moves through the VCS from your production org to lower environments for editing and back through the VCS to your production org (you no longer deploy directly from org to org).

Similar to how you likely work now, you first propose production data changes and develop your new features in a separate org to protect the data in your production org. Under version control, this process starts by deploying data from the VCS to seed a sandbox or development org via a VCS repository branch. Then when you’ve completed your develop work, you save the org changes back into the VCS branch, merge the org branch back into the main branch, and deploy the changes from the main branch to your production org.

The Release tab is where you:

• Turn your orgs into managed orgs.
• Deploy data from VCS branches to their associated orgs.
• Save data you edit in the Salesforce orgs back to their VCS branches.

Workflow 

To maintain data integrity and tracking, you build and operate your change management environment in this order:

1. Start by identifying the Salesforce org containing your source of truth data and installing the Prodly managed package in that org to become your control org.
2. Identify the VCS account to use for version control and set read/write and public/private access permissions.
3. Establish a connection from Release to an existing VCS repository within your VCS account.
4. Select the objects that contain the data you desire to place under version control and initiate the initial data save to the repository. (Refer to step 1 in the diagram above.)
5. Turn an existing sandbox, development org, or scratch org into a managed org, deploying a copy of the main branch data to it. (Refer to steps 2 and 3 in the diagram above.)
6. Make your changes and develop your new features in the sandbox.
7. Save the sandbox changes back to the VCS branch. (Refer to step 4 in the diagram above.)
8. Merge the sandbox branch into the main branch. (Refer to step 5 in the diagram above.)
9. Deploy the main branch changes to your control org. (Refer to step 6 in the diagram above.)

Scope 

The current release of Release version-control deployment has these constraints:

• Integrates with the Microsoft Azure Cloud, Bitbucket Cloud, GitHub Cloud, and GitHub Enterprise version control systems.
• 1-to-1 association between the VCS repository and the Release installation (no multiple repository support).
• 1-to-1 association between a VCS branch and a Salesforce org.
• The repository can be initialized only with data from the control org (where Release gets installed).
• Objects placed under version control always and only come from the control org schema.
• When New Managed Org creates a repository branch, all main branch data gets copied to the branch and also to the Salesforce org.
• Record filtering is not yet available.

Release supports Salesforce objects with these attributes:

• Accessible
• Creatable or updateable
• Not deprecated
• Queryable

Release supports these Salesforce object field attributes and types:

• Accessible
• Createable or updateable
• Not deprecated
• Not a polymorphic Lookup
• Not a system field
• Lookup relationship
• Checkbox
• Currency
• Date
• Date/Time
• Email
• Number
• Percent
• Phone
• Number
• Percent
• Phone
• Picklist
• Picklist (multi-select)
• Text
• Time
• Text (encrypted)

These Salesforce object field types are not supported for version tracking:

• Auto Number (retrieve only, cannot deploy)
• Formula (retrieve only, cannot deploy)
• Geolocation (retrieve only, cannot deploy)
• Rollup summary (retrieve only, cannot deploy)
• External lookup relationship
• Binary
• Lookup fields to unmanaged objects

Future development plans that Prodly is evaluating include:

• Providing branch merge and rollback capabilities from within the Release user interface.
• Providing more options during repository branch creation and associated org seeding.
• Providing record filtering and other org-to-org deployment options.
• Supporting metadata deployment.

Org-to-Org Deployment and the VCS

Overview 

In addition to all the power and functionality org-to-org deployment provides, you can also save snapshots of your org reference data to the version control system (VCS) at any point in time for versioning or backup, then roll back the changes at a later date if necessary.

Workflow

To include capturing snapshots of your org reference data to your org-to-org deployment workflow, you add operate version control in your org-to-org deployment environment in this order:

1. Start by setting up the VCS integration to your existing Azure, Bitbucket, or GitHub or account from the Settings page of the Release tab.

2. Under the Release tab, create managed orgs for the orgs you desire to back up.
3. At any point in time after that (typically after a significant org-to-org deployment), use Save to Branch on the card to save a snapshot of your reference data to your VCS.
4. If necessary at a later date, use the functionality provided in your VCS software to roll back the changes. 

Scope

In addition to most of the items listed in the version-control deployment scope, the current release of Release version control for org-to-org deployment has these constraints:

• Snapshots are of reference data only.