The software industry uses various practices for releasing new software to ensure the stability and security of existing systems, and the smooth deployment of new ones.
Installing DI software usually involves the deployment of at least three environments:
-
One for development work (DEV)
-
One for testing efforts (UAT)
-
One for production (PROD)—the so-called live system.
Starting with Workbench 7.1(14), the version control features support DTAP, which is a phased approach to software development, testing, acceptance, and production. Adopting DTAP as an integral part of your release management can:
- Uncover and correct mistakes during testing
- Prevent errors from slipping into production
- Create an audit trail of all software edits
- Control changes that are put into production
- Validate releases with key end users
- Prevent data corruption from software errors
- Control the rollout of new software by staging the process in separate environments
DTAP Configuration Options
How does DTAP work? Think of it as a set of environments:
- Development for all code changes
- Test for validating code
- Acceptance for validation by key users
- Production for end users
You can also designate separate servers for backups and education or training. How you configure DTAP should address the needs and scope of your project. You can skip or combine certain environments. For example:
- D/T/A/P
- D/TA/P
- DT/A/PB
- DTEA/PB
- …
The separation of the work flow can be privilege-based. For example, developers do not have direct access to production data. Separate servers allow for separate and controllable data sets.
The following diagram shows a typical configuration with three environments.
Implementing DTAP is easier if the software development process includes version control.
What is version control?
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Workbench uses Git, a free and open source distributed version control system to track changes in source code during software development.
Git uses local files for working copies, plus a repository with metadata. Changes are committed to a local repository before posting to the remote central repository. The central repository holds all finalized changes.
Why use version control?
Using version control allows multiple developers to work on a code set without compromising integrity. You can audit all changes to the code: who made the change, what the change was, when was it made, how was it made, and why. You can bundle a set of changes, test them, and then create a release. Commits create backups that you can use to revert a version. If properly configured, version control supports switching to a different release for a DTAP environment in seconds.
How does version control work?
Think of a tree with branches. A branch is a copy of a specific work-in-progress code set. When a branch is complete, it can be merged into the trunk. If deemed as unacceptable, a branch can be removed without affecting the trunk.
When merging branches, Git can resolve most conflicts if the changes are on different lines. Although there are tools to help resolve collisions, Developers should make an effort to avoid working on the same files simultaneously.
Git Version Control
Git is a distributed version control system. Each user can have a local copy of the code and a repository, all pointing back to the trunk or central repository. A commit command saves the delta of files to the local repository; a push command saves the delta to the trunk or central repository.
Distributed Version Control System
In the Workbench environment, a Project holds both the working copy of files and the local Git repository with committed changes to those files. You can establish the central repository on a shared disk or on a different machine on the network. Another option is GitLab, which offers a free cloud version of a Git central repository. For more details about Git, see https://git-scm.com/.
TIP: Use of version control commands in a project that does not have a Git repository configured causes Workbench to initialize a local Git repository in the project root. This is how Workbench version 7.0 handles its basic version control using Git.
What Files are backed up?
Version control deals with text files, not binary format files. It backs up scripts that manipulate the data, not the data itself. Only static files are backed up, not dynamic files—those created whenever a process runs. For example:
Files in Version Control
| Yes | No |
|---|---|
| /programs/*.* | /data/*.txt |
| /config/my-config.template | /config/my-config.txt |
| /views/*.dvp (static) | /views/*.dvp (dynamic) |
| /views/*.rep | /generated/* |
| /models/*.cplan | /models/*.cbase |
Basic Git operations
Workbench uses Git terminology and operations. Some basic commands to be aware of are listed below. Some of the operations run in the background, meaning you will not see them in the Workbench UI.
Branch—Create a new branch
Checkout—Switch from one branch to another; create a new branch and switch to it
Clone—Obtain a repository from an existing URL
Commit—Record the file permanently in the version history; save to local repository
Merge—Merge the specified branch’s history to the current branch
Pull—Fetch and merge changes from the remote server (central repository) to your working directory
Push—Send the committed changes in the local repository to your remote repository; pushes all branches to your remote central repository (not local)
Reset—Undo all commits that occurred after the specified commit, and preserve the changes locally; discard history and go back to a specific commit
Tag—Assign a tag to the specified commit
Git Terms
Repository: Information required to create files, including histories of all changes made to them, saved in a special directory.
Working Copy: Actual files from a repository, such as Integrator scripts, lookup tables.
Clone: Make a copy of a repository, and establish its ancestry relative to another remote repository.
Push/Pull: Move changes from one repository to another—Pull from remote, Push to remote.
Commit: A set of changes to one or more files updated to a local repository.