This article introduces the management of Agilitest projects with a Git repository hosted on Bitbucket.
What is Bitbucket?
Bitbucket is a service offered by the Atlassian company, which allows the hosting and versioning of files using Git. It is well known in the corporate world, easy to use, and allows a perfect integration with Jira, a bug tracking system developed by the same parent company.
The management of Git repositories is done from the web interface of the SaaS service, but a desktop software is available to perform files staging and commit operations. It is called Sourcetree.
For the purposes of this article, the Sourcetree software has been configured in English for greater clarity on the original Git terms: Stage, Commit, Pull, Push, Fetch, Branch, Merge, Stash. Moreover, not all the terms of the application are translated from English.
For the purpose of this article, it is therefore necessary to have a Bitbucket user account, and the Sourcetree software in connected mode. The connection of Sourcetree with the Bitbucket account can be done through the login credentials, or through API tokens that are created on the Bitbucket back office in Personal settings > App passwords > Create app passwords.
SourceTree has been configured to use the "system" installation of Git and not the embedded version which can sometimes cause authentication problems for repository clones.
Setting up an Agilitest project managed with Git
The first step is to create a Git repository from the Bitbucket web interface or from the Sourcetree software in connected mode.
Creating an empty repository
From the software, go to the Local tab, click on the Create button.
Enter the path of an empty folder to contain the repository on the local hard disk, as well as the name of the repository (here repository-test). Tick Create Repository On Account and select the Bitbucket account on which to synchronise the repository (Account, Owner, Description). Tick "Is Private" to avoid publishing your content in open-source in full view of everyone.
Setting up an Agilitest project in the repository
In local operation, without Git, Agilitest allows you to create new projects. These projects are populated automatically with a default tree structure that includes libs, src, target, etc.
But in this case we started by creating the empty project folder (to make it a repository). So we need to copy the elements of an empty project into our Git repository folder (here, repository-test). One way to do this is to create the repository-rest-2 project in Agilitest and copy and paste its contents into repository-test. Be careful however to update the README.md, .atsProjectProperties, and pom.xml files to adapt the correct project name.
Another way is to create the Agilitest project first, move its content elsewhere, initialize the Git repository, put back its content, then Stage and Commit the repository.
At this step, we are at level zero of the project and ready to start. It's time to Commit.
To do this, go to Sourcetree: Unstaged files > Stage all, then click on the Commit button at the bottom right. Be careful not to confuse this with the Commit button at the top left.
The project is thus "snapshot" in its initial state and, in the future, it will be possible to return to this state. To synchronise the repository and its commits on the Bitbucket server, click on the "Push" icon.
A question that often comes up is how often to commit. To answer this question, let's take a look at the notion of atomic commits, which it is advisable to respect:
- A commit concerns only one task: a test maintenance, an evolution of an ATS test, a new ATS scenario, etc.
- A commit does not break the consistency of the repository by preventing the execution of the tests or the campaign.
- A commit must be associated with a concise and explicit message.
Possibilities offered by this configuration
The possibilities offered by this Git Bitbucket repository are the same as for any Git repository:
- Versioning of Agilitest projects and in particular of .ats files.
- Collaborative work between several automation profiles on the same project, and in particular the notion of Merge.
- Synchronisation of project folders between the Git repository, the automation roles, and the execution server. Git is thus a pillar of the CI/CD chain.
Note that report retention is usually handled by Jenkins, with the retention of artefacts from each job launch (#1, #2 etc), rather than by versioning of runtime report files.