There are a number of ways developers can agree to implement DTAP for source control when using Workbench. Basically, programmers have a working copy of the code that they update, test, and commit locally. Once they are ready to share the code, they push it to the central repository where it is available to other developers to pull and merge those updates to their local working copies. This is all part of "development".
Beyond local working copies, the final code changes pushed to the central repository can be pushed and pulled as needed on different testing and acceptance servers. In general, pulling to the production server is done once when all updates are finalized. Generally there is no plan to push from the production environment back to the central repository.
In Workbench, a project holds both the working copy of the code files, as well as the local Git repository. The different developer projects can be defined on the same server using different directories, on different servers, on the same DiveLine using different project names, or on different DiveLines with different port numbers. Developers should discuss and agree upon a scheme that supports their needs.
For the central repository, there are also multiple options. The central repository can be located on the same machine as the working copies, on a different machine on the network, in shared disk space, or in the cloud.
More ideas for working with version control can be found here: https://git-scm.com/about/distributed
There are two ways to clone a repository in Workbench, one of which involves creating a new Workbench project and one of which clones the repository to an existing Workbench project:
-
You can create a new Workbench project and choose to clone from Git. See Creating a New Project with Git.
-
You can clone a Git repository to an existing Workbench project using the GUI. See Cloning Repositories.
Initial Clone on UAT and PROD
Clone the central repository to the test and production servers. That is, create test and production projects such as UAT-git-in-wb and PROD-git-in-wb. This step establishes ancestry relative to the remote repository.
For example, for testing purposes, create:
This creates the test version of the project on the server. You can open it in Workbench, check its content, and start your testing procedures.
Likewise, for production purposes, create:
This creates the production version of the project on the server.
NOTE: When PROD is created on a separate DiveLine connection, you can prevent commits by enabling the readonly option for the project's version control. See Version Control for the Server.
Test on UAT
Once the project is available on the test server, you can open it in Workbench and start running tests.
You can continue to make changes and commits on DEV. When ready, push them to the central repository. See Pushing Changes.
You can pull the latest changes from the central repository to UAT for more testing. See Pulling Changes.
Release to PROD
On DEV, you will prepare the release. Be sure all features and bug fixes work; comment out any unfinished work. See:
On PROD, check the status and pull down the new release. See: