Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Understanding best practices for version control in the DevOps pipeline

Updated on April 5, 2022

Change the application version number each time you deploy changes to a production system. As a best practice, use semantic versioning, because it offers a logical set of rules about when to increase each version number.

When you use semantic versioning, the part of the version number that is incremented communicates the significance of the change. Additional information about semantic versioning is available on the web.

The version number, in the format NN-NN-NN, defines the major version (first two digits), minor version (middle digits), and patch version (last digits), for example, 03-01-15.

  • Major versions include significant features that might cause compatibility issues with earlier releases.
  • Minor versions include enhancements or incremental updates.
  • Patch versions include small changes such as bug fixes.

Rulesets include all versions of each rule. Skimming reduces the number of rules by collecting the highest version of rules in the ruleset and copying them to a new major or minor version of that ruleset, with patch version 01. For more information about skimming, see Skim to create a higher version.

Best practices for development

Follow these best practices for version control in development:

  • Work in branches.
  • Consider creating a major version of your application if you upgrade your application server or database server to a major new version.
  • For small single scrum teams:
    • Increment both the patch and the minor version during every merge.
    • Developers merge into the next incremented patch version.
  • For multiple scrum teams:
    • Assign a user the role of a release manager, who determines the application version and release strategy. This user should be familiar with concepts and features such as rulesets, ruleset versioning, application records, and application migration strategies.
    • The release manager selects a development ruleset version number that includes a patch version number.
    • Developers merge into the highest available ruleset version.
    • Frequently increment ruleset versions to easily track updates to your application over time.
    • Maintain an application record that is capped at major and minor versions of its component rulesets.

Best practices for deployment

Follow these best practices when you deploy your application to production:

  • Define target ruleset versions for production deployment.
  • Use lock and roll to password-protect versions and roll changes to higher versions. For more information, see RuleSet Stack tab.
  • Increment the ruleset version every time you migrate your application to production, unless the application is likely to reach the patch version limit of 99.
  • Create restore points before each deployment. For more information about restore points, see Using restore points to enable error recovery.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us