Return to main navigation Page
Source control refers to the process of tracking changes across types of “source code” that can be used to generate the application. Versioning is a more general term that refers to keeping snapshot revisions of each major version of a particular resource. For more information, including a reference to many of the terms you will see here, see http://en.wikipedia.org/wiki/Revision_control.
Keeping track of changes, and why they were made, is important for any project. It supports:
You should use source control anywhere you have code. In addition, it is usually a good idea to keep all major versions of any other types of documents (for example, datasheets, contracts), especially if they are published or distributed in some form. CPQ Cloud does not have versioning built in, but there are a variety of other tools that you can use.
The first step is to get a good version control system. There are a number of these, many of them free. If you have a standard within your organization, that is usually the best one to use. If you do not have a standard that your CPQ Cloud admins are already using, here are a few that you can try:
Next, you need some policies and guidelines. This is really dependent on your development procedures, but here a few recommended practices:
Version control everything that you can.
Check in often.
The smaller the individual changesets are, the easier it will be to determine what the purpose of each one is. A good rule of thumb is, commit your changes whenever you click Apply or Update to save your changes in CPQ Cloud. One of the benefits of a distributed version control system like Mercurial is that you can do this without impacting other users, since commits are local by default.
Pay especially close attention to scripts that more than one user are working on (common configuration rules or commerce pricing functions, for example).
If you are a developer in one of those scripts, and you know that other users are working on it, make sure to GET the latest version before making any modifications of your own, rather than reusing a version you have saved offline.
Make sure your system automatically tags changes with the user that makes the change, or make it a matter of policy to do so.
Usually, when you want to know what a piece of code does, the best person to ask is the original developer, and this makes it much easier to know who that was.
If your system allows it, add a COMMENT to each checkin/commit in order to track what PURPOSE the changes are meant to address.
This is a good place to put a reference to a case, requirement, or design feature, that the code implements. Internally, we use Salesforce.com Cases to track almost everything we build, so we have a standard field for case number that automatically links to the Case, but a simple text comment works as well.
Ensure that you can revert to earlier versions, and know how to do so.
This is especially important in a crisis situation, when you want to be able to recover quickly and efficiently, and often a revert is the best way to accomplish this.
Other Solution Components
Some elements (for example, Attributes, Simple Rules) are not easy to put under version control because they are not expressed as text. In practice this rarely creates an issue, since these components are fairly simple to modify/delete/recreate, but if you are concerned about this, there are a few steps you can take: