Best Practices and Limitations

Using a version control system adds both power and complexity to your environment. This topic offers some best practice tips on what to do to succeed and not do to avoid frustration.

Version Control Best Practices

Initializing the Version Control System Repository

Prodly recommends starting with a new VCS repository containing only the default main branch. We recommend initializing the branch directly from your control environment (typically production environment) using the setup wizard.

This data then becomes your starting point from which to track changes. Release is purpose-built for admins and powerful for development teams as well. By using your production data schema from the start, you can most-easily branch data into individual dev or scratch environments for you to begin data driven development. Then you can make changes (such as updating product bundles and price rules) per your change management process separately and merge the changes back into the main branch using the VCS to resolve any conflicts.

Deleting Records

By default as a safeguard, Release does not delete records from a destination environment. Once enabled, when you delete a record from an environment, your next Save to Branch action deletes the record from the branch and tracks the deletion. Then, any subsequent merge to another branch deletes the record from the branch, and then a Deploy to environment action deletes the record from the associated destination environment.

<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" />

If you roll back the changes to a point that included the record, Release recreates the record with the audit fields reflecting the date of recreation, not the original creation date.

</aside>

Protected and Locked Branches

Protecting key branches (like main, UAT, or production) is a crucial best practice used to prevent accidental changes and enforce a formal review process, ensuring that all updates are approved through a pull request before being integrated into your source of truth.

Bitbucket, GitHub, GitLab, GitHub Enterprise and Azure users are able to protect and/or lock branches in their repositories. If a branch is locked or protected, Prodly will be able to successfully connect to it to complete Deploy from branch operations. Prodly will not complete a Save to branch operations when the branch is protected or locked.

When setting up Version Control using a locked or protected branch, the initial commit (Save to branch) will fail, however, the connection status will remain connected so users can Deploy from branch. Users will also see an error to indicate that the Save to branch operation has failed due to the branch being protected or locked.

Practices to Avoid

Deleting a Connected VCS Repository

Deleting the repository from within the version control system will break the connection with Prodly. If you need to delete the repository, removing all the data change history, first disconnect the repository from Prodly.

Using a Public Repository