Two standard workflows embraced by GitHub users are the Fork & Pull Workflow, with developers working on their personal copy of a repository (common for open source), and the Branching Workflow, with developers sharing repositories using multiple branches.

Git Branching Workflow

For software teams following the branching workflow, this article explains how Testspace helps manage the quality of their software development process. (Fork & Pull will be covered in another article)

By collecting and analyzing data from the Continuous Integration (CI) Workflow, Testspace provides valuable insights into the CI workflow efficiency and test effectiveness.

The keys to the Analysis and why it Works

The keys to how, and why, Testspace Analysis provides effective results:

  1. All data from all sources – test results, code coverage, static analysis, custom metrics, code churn, and defects – are combined into a single record of health.
  2. Health records are maintained and charted for every branch – master, feature, and topic – across every repository over time.
  3. Development teams simply follow their normal workflow

By connecting your Testspace account to your GitHub Organizations, collecting data from every branch, for their entire lifecycle, becomes automatic.

Adding Testspace to the CI process is trivial and once setup:

Connecting to the GitHub Service and Repositories

With Testspace Connected Services, there are no plugins or extensions to install, the Testspace account owner – logged into Testspace with their GitHub credentials – simply connects to their GitHub Service.

GitHub Organizations

Read more

Creating a new, connected Project in Testspace involves selecting a repository from a GitHub Organization.

Adding Testspace to your Online CI

Adding Testspace to online CI is merely adding a client utility to the install process. Using Travis-CI, as an example, the addition to the yaml configuration file is simply

 - mkdir -p $HOME/bin
 - curl -fsSL | tar -zxvf- -C $HOME/bin 
 - testspace config url
 - testspace results*.xml coverage.xml ...

Branching and Adding Commits

At the heart of the Git Branching Workflow are Topic (or Feature) branches; short term branches used for a single feature or defect. Topic branches are used by developers to create, work on, merge, and delete often several times a day. For this workflow to be both effective and efficient

New spaces are automatically created the first time data is pushed on a new branch.

GitHub Branching

Metric charts for every data source – test, analysis, coverage, etc. – are created automatically for every new branch.

Each new Space is given a copy of the most recent health record from its base Space at the moment the branch occurs. All metric deltas and trends monitored over time are based on the first health record.

Each time a commit is added – triggering CI – new data is pushed to the Space, and all criteria and thresholds are applied. All resulting metrics from all data sources are aggregated into a single indication of health for each commit. Each new health record links back to the commit details in GitHub

GitHub Branches and Commits

The single health indicator provides GitHub with a single check, encapsulating all definitions of health, and with all Details accessible from the one link.

GitHub Commits Check

Opening Pull Requests and Merging

After opening a pull request, and all metrics from all sources have met their health criteria, trends provide valuable data and insights when discussing changes that have occurred on the branch.

Development and master branch leads can make informed decisions before merging back to the base branch

trends for test, static analysis, code coverage, and memory consumption

All trends, code churn, health statistics, and all rates of change for each branch are maintained by the Testspace Project regardless if the branch becomes deleted.

Get setup in minutes!

Try Testspace risk-free. No credit card is required.

Have questions? Contact us.