How Can We Help?
Version Control – Distributed Version Control System Integration
Version Control
Enterprise Tester integrates with a number of popular Distributed Version Control System (DVCS).
This integration will transparently commit copies of baselines created for a project or package to source control, allowing test artefacts to be stored in a source code repository, allowing correlation of test artifacts with versions of a software code base.
Initial Setup
To enable version control integration with Enterprise Tester, the general steps are:
- Login to the Enterprise Tester server using the same user account as Enterprise Tester has configured for it’s application pools identity in IIS.
- Install the command line client tools for you version control system onto the Enterprise Tester server.
- Checkout/clone your version control repository to a local directory on the Enterprise Tester server.
- Attempt a test commit to confirm it is working from command line (i.e. if using GIT + SSH this will ensure you have setup the SSH keys correctly, or if using NTLM this will ensure your windows identity has permission to access to the repository).
- If everything is working correctly, proceed to configure the version control settings at either the project level, or organisation + project level for each project you want to support version control with.
- Attempt to baseline a small package of requirements or scripts in your project, and confirm the baseline was pushed to your version control system.
- If that works, you should be ready to start using version control integration with baselines.
Configuration
Version control can be configured at an organisation or project level.
- To configure version control settings for an organisation, go to Admin -> Organisations -> Edit Organisation, then switch to the Version Control tab.
- To configure version control settings for a specific project, go to Admin -> Organisations -> Projects -> Edit Project, then switch to the Version Control tab.
In each case you will be required to supply the following details:
Key | Value |
|---|---|
| Type | Type of version control repository to integrate with |
| Repository Url | Url of the repository – this could be a standard HTTP URL, but depends on the type selected (for instance when using git it’s OK to use an SSH style url) |
| Working copy path | Where the repository is checked out to (this is where the baselines will be stored on the local disk) e.g. c:\data\baselines\ Note: currently the working directory must be created and checked out initially by the user, Enterprise Tester will not perform an initial checkout itself |
| Username | The username of a user with permissions to commit to the repository, in some cases this can be left blank i.e. when using SSH, or when the repository allows anonymous writes |
| Password | The password of a user with permissions to commit to the repository, in some cases this can be left blank i.e. when using SSH, or when the repository allows anonymous writes |
| Executable Path | This is the path (including filename) to the executable used to perform the source control actions so for example if using GIT integration, you would need to have git for windows installed, and you would then configure the executable path to be: c:\Program Files (x86)\Git\bin\git.exe |
| Additional Arguments | Any additional arguments specified will be automatically added to every command executed using the executable (specified in Executable Path) – this is useful in the case of troubleshooting for instance, where you may want to pass in additional flags to force more verbose error messages and logging |
Once you have configured version control an organisation level, to then use that version control repository you must configure the project repository to use the value “Inherit From Organisation” for the version control type.
In this case project baselines will stored in child folders, based on the name of the project. If version control settings however are configured directly at the project level, baselines will be stored directly into the working directory folder.
GIT
GIT is a popular DVCS (Distributed Version Control System) – supported by Enterprise Tester version 4.4 and above.
Setup
Installing GIT for Windows
To setup GIT integration, you must first install Git for Windows – which can be downloaded from the git-scm.com website.
Once downloaded, run the installation on the Enterprise Tester server.
Last of all, you will want to add the git “bin” folder to your path, to do so:
- Go to Control Panel -> System & Security -> System -> Advanced System Settings -> Environment Variables.
- In the System Variables section, locate “Path”.
- Click the edit button, then append the full path to the “bin” folder in your git installation directory (where git.exe exists) to the URL, prefixed by a semicolon.
- Click OK to save changes.
You should now be able to launch a command prompt and type “GIT” and see a version message like so:
C:\> git
usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--inf-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
[-c name=value] [--help]
<command> [<args>]
....
Cloning your Repository
Next you need to clone your repository to a local directory on your Enterprise Tester machine. It the case of bitbucket or github, you can find the URL and directions on how to clone your repository on the home page for the repository.
If you intend on using SSH with a service such as github or bitbucket then you will need to:
- Login to the server using the same username as the identity configured for the application being used by Enterprise Tester.
- Generate an SSH Key (be sure to NOT password protect the SSH Key)
- Add it to your github or bitbucket account.
Github provide a handy guide on how to generate an SSH Key.
At this point you should now be able to clone the repository to a local directory of the machine – so commence with the clone, here an example of cloning from bitbucket:
git clone https://jbloggs@bitbucket.org/jbloggs/jbloggs_et_project.git
Once cloned, you may need to switch the branch of the repository to the branch you want Enterprise Tester to commit to (this can be done using the git checkout command).
git checkout QA
Check Commit Works
Once you have cloned the repository, we suggest performing a test commit (this will allow you to ensure that if using SSH, git does not prompt for a password when committing, and allows you to permanently accept SSH/SSL certificates etc.)
You can do this by:
- Creating a new text document call test.txt in the working directory.
- Executing the command: git add .**
- Execute the command: git commit -m “test commit”
- Execute the command: git push
You should see the new file is added to the remote git repository on the correct branch.
Setup
You are now ready to configure Enterprise Tester at either the project or organisation level – a standard GIT configuration when using a git repository hosted on bitbucket may look like this:
Testing
Once you have setup the configuration for your project, you can test the connection by creating a baseline for a small requirements or scripts package. You should be able to confirm it worked by checking the list of recent commits for your git repository on the remote server.
How it Works
The command flow executed by the synchronizer when creating a baseline for a project with git integration turned on is:
- git rev-parse (used to confirm working directory is part of a git repository)
- git pull or git pull {url} (if repository url specified in config)
- git add {filename}
- git config user.email “{email}” (if user.email not configured globally or locally for repo)
- git config user.name “{full name}” (if user.name not configured globally or locally for repo)
- git commit -m “{commit message}”
- git push (will use default remote configured for local branch via track, you can also manually configure this as per this stackoverflow post)
Perforce
Enterprise Tester supports integrating with Perforce version control when creating baselines.
Prerequisites
You must have the perforce command client installed onto the Enterprise Tester server for perforce integration to work (p4.exe). To install it go to the perforce website and download the version of the client applicable for your perforce version.
Once installed, you will normally find the executable is available at this path: C:\Program Files\Perforce\p4.exe
Setup
Perforce integration relies on setting up a workspace on the local disk of the Enterprise Tester server, pointing to the depot on the perforce server.
Once setup you can then configure Enterprise Tester at the project or organisation level, specifying the location of the p4 executable, the workspace folder, and the login and password to use when accessing the perforce depot (login/password are optional).
Subversion (SVN)
Enterprise Tester supports integration with subversion when creating baselines.
Download and Install Subversion Client
On the Enterprise Tester server, download and install subversion – we generally suggest using the SilkSVN or CollabNet packages.
The installation should automatically add subversion to your path, you can normally confirm this by launching a command prompt and typing “svn”, you should see something like this if subversion is installed:
C:\> svn Type 'svn help' for usage.
Checkout the Subversion Repository
Next you need to checkout the subversion repository to a folder on the local machine, this can be done using a command like so:
svn checkout https://svn.corpserver.com/svnroot/myproject/trunk/baselines baselines
This will checkout the repository with the URL “https://svn.corpserver.com/svnroot/myproject/trunk/baselines” to the folder “baselines” within the current directory.
Configure Version Control Settings
Here is an example the configuration necessary for Subversion to work on a standard windows server:
Test Setup
At this stage you are now ready to test the functionality, we suggesting creating a baseline for a small package – if you receive no errors when creating a baseline, review the commit history for your subversion repository and confirm the baseline.zip file was added correctly.