When using DTAP and version control in Workbench, the idea is to work on the DEV server, test on the UAT server, and release to the PROD server. Best practices for successful release management include:
-
Turn off any automatic Version Control commits. This prevents expanding the logs with "Auto-Commit" entries.
-
Be sure each developer visits Tools > Preferences > Version Control to set their name and email so their commits are properly identified.
-
Try to work on different code sets to minimize conflicts that require resolution when pushing and pulling changes to and from the central repository.
-
Use an issue-tracker number as a suffix to the commit message when performing a commit, for example. "Added homepage markers (#234)". That makes it easier to link changes back to features or bugs.
-
Prevent untracked changes on the DEV server by committing often, for example, every hour or when finishing a small task. Try to not commit broken code. Each commit gives you a checkpoint—a recovery point.
-
Ignore configuration files that are different between DEV, UAT and PROD. For convenience, add a template of the config file to version control, that is config.txt used in code is ignored and versioned as config.txt.template or config.txt.dist.
-
Do not version a single file that will change at run time. For example, hard coded defaults in markers, models that are added to DivePlans through scripts, environment specific configuration files, or data/lookup files. Create template files, and add these to version control.
-
Never make changes on PROD—always pull from the central repository. Use the Server Settings option to make version control read only on PROD. See Version Control for the Server.
-
When cloning projects, aliases need special handling.