Reference Deployments
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
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:
: This is the most basic deployment which does not make use of a CI/CD system and thus entails most manual effort.
: 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.
: This deployment is suitable if your CI/CD system tends to be slow on pull requests.
: 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.
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.
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.
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.
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.
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.
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.
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.
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.
You need to on a central server and and on developer workstations. is configured on developer workstations so that you can track Diffblue usage.
You need to on a central server and and on developer workstations. is configured on developer workstations so that you can track Diffblue usage.
You need to on a central server, in your CI/CD system and and on developer workstations. is configured on developer workstations and in your CI/CD system so that you can track Diffblue usage.
You need to on a central server, in your CI/CD system and and on developer workstations. is configured on developer workstations and in your CI/CD system so that you can track Diffblue usage.
