Reference Deployments
A Cover deployment consists of multiple components (Plugin, CLI, Pipeline, Reports), which need to be installed and configured to interact with your CI/CD infrastructure and among each other correctly.
We strongly recommend to strictly follow below reference deployments as deviations from them can lead to a dysfunctional deployment.
Depending on the properties of your CI/CD system, Cover can integrate in a few different ways so that you get most from your Cover deployment:
No CI/CD System Available: This is the most basic deployment which does not make use of a CI/CD system and thus entails most manual effort.
Minimal CI/CD System: This deployment is suitable if you are not ready for creating tests in your CI/CD system, but still want to benefit from automated reporting.
Slow CI/CD System: This deployment is suitable if your CI/CD system tends to be slow on pull requests.
Fast CI/CD System: If your CI/CD system tends to be fast on pull requests then you can take advantage of writing and updating new tests on each pull request.
Reference Deployment 1: No CI/CD System Available
This is the most basic deployment which does not make use of a CI/CD system and thus entails most manual effort. You have to trigger all actions manually from developer workstations. See diagram below.
You need to install Cover Reports on a central server and Cover CLI and Cover Plugin on developer workstations. Telemetry is configured on developer workstations so that you can track Diffblue usage.
The developer onboarding a new project creates the initial test baseline using Cover CLI and uploads coverage data to Cover Reports. On each Cover release, a developer refreshes the baseline using Cover CLI and uploads coverage data to Cover Reports in order to track test coverage across your projects. Developers use Cover Plugin day-to-day to write and update tests.
Reference Deployment 2: Minimal CI/CD System
This deployment is suitable if you are not ready for creating tests in your CI/CD system, but still want to benefit from automated reporting. See diagram below. The difference to Reference Deployment 1 is that it automates uploading coverage data to Cover Reports, enabling more frequent tracking of test coverage across your projects.
You need to install Cover Reports on a central server and Cover CLI and Cover Plugin on developer workstations. Telemetry is configured on developer workstations so that you can track Diffblue usage.
The developer onboarding a new project creates the initial test baseline using Cover CLI and uploads coverage data to Cover Reports. Developers use Cover Plugin day-to-day to write and update tests. CI is configured to run periodically, e.g. nightly, on the stable branch, e.g. main, of the project to create and upload coverage reports to Cover Reports in order to track test coverage across your projects. On each Cover release, the baseline is refreshed using Cover CLI and coverage data uploaded to Cover Reports.
Reference Deployment 3: Slow CI/CD System
This deployment is suitable if your CI/CD system tends to be slow on pull requests. See diagram below. The difference to Reference Deployment 2 is that
test baselines are triggered automatically and refreshed more frequently, and
coverage data is automatically uploaded to Cover Reports on merging pull requests.
You need to install Cover Reports on a central server, Cover Pipeline in your CI/CD system and Cover CLI and Cover Plugin on developer workstations. Telemetry is configured on developer workstations and in your CI/CD system so that you can track Diffblue usage.
The developer onboarding a new project creates the initial test baseline using Cover CLI and uploads coverage data to Cover Reports. Developers use Cover Plugin day-to-day to write and update tests. Coverage data is uploaded to Cover Reports whenever a pull request is merged in order to track test coverage across your projects. CI is configured to run periodically (e.g. weekly) to refresh the baseline and to upload coverage data to Cover Reports.
Reference Deployment 4: Fast CI/CD System
If your CI/CD system tends to be fast on pull requests then you can take advantage of writing and updating new tests on each pull request. The difference to Reference Deployment 3 is that tests are added incrementally in the pull request workflow.
You need to install Cover Reports on a central server, Cover Pipeline in your CI/CD system and Cover CLI and Cover Plugin on developer workstations. Telemetry is configured on developer workstations and in your CI/CD system so that you can track Diffblue usage.
The developer onboarding a new project creates the initial test baseline using Cover CLI and uploads coverage data to Cover Reports. Developers use Cover Plugin day-to-day to write and update tests locally. When developers push their code then Cover writes new tests that developers haven't written locally, updates existing ones and commits the changes to their pull request branch. Coverage data is uploaded to Cover Reports whenever a pull request is merged in order to track test coverage across your projects. CI is configured to run periodically (e.g. weekly) to refresh the baseline and to upload coverage data to Cover Reports.
Last updated
