As a developer,
I want to integrate SonarQube into our CircleCI pipeline,
So that we can ensure our TypeScript codebase maintains a high standard of quality and meets the minimum test coverage threshold of 80%.
Definition of Done
SonarQube is successfully integrated into the CircleCI pipeline, and configuration files (e.g., sonar-project.properties, .circleci/config.yml) are properly set up and committed to the project repository.
Testing tools are configured to generate coverage reports in lcov format.
Coverage reports are automatically combined and fed into SonarQube during the CI process without manual intervention.
The custom quality profile for TypeScript is active and configured in SonarQube.
Quality gates are set up to ensure that no code with less than 80% coverage is merged into the main branch.
Documentation detailing the SonarQube and CircleCI integration, configuration steps, how to interpret SonarQube reports, and how to resolve issues flagged by quality gates is completed and accessible to all team members.
All sensitive data, including access tokens and credentials, are securely stored using CircleCI's environment variables or secret management features.
Acceptance Criteria
AC1.1:
Given that the team requires a code quality analysis tool,
When they access the SonarQube server,
Then they should find it properly configured and accessible.
AC1.2:
Given the need for secure integration with our CI/CD pipeline,
When the team attempts to connect to SonarQube,
Then they should be able to use secure credentials and permissions already set.
AC2.1: => new story
Given a project repository,
When a developer commits to the main branch,
Then a CircleCI job should trigger that includes SonarQube scanning steps.
AC2.2: => new story
Given the CI/CD pipeline in CircleCI,
When SonarQube scans are run,
Then caching is used effectively to optimize build times for Node.js dependencies.
AC3.2: => new story
Given individual lcov coverage reports,
When the CI process runs,
Then these reports are combined into a single lcov file before SonarQube analysis.
AC3.1: => AC for vitest and cyprus test story
Given multiple testing tools are used in the project (e.g., Vitest, cypress),
When tests are executed,
Then each tool should generate coverage reports in lcov format.
AC4.1:
Given a TypeScript project,
When configuring SonarQube,
Then the sonar-project.properties file should be specifically set up for TypeScript including necessary exclusions and inclusions.
AC5.1:
Given a need to maintain high code quality,
When a developer pushes new code,
Then the SonarQube quality gate should only pass the code if it has 80% or more coverage.
AC5.2:
Given the active SonarQube quality gates,
When analyzing the code for quality metrics,
Then the gates should also consider bugs, code smells, and vulnerabilities.
AC6.1:
Given the new setup of SonarQube in CircleCI,
When team members look for guidance,
Then they should find complete documentation on the setup and troubleshooting.
AC6.2:
Given the complexity and newness of the integrated tools,
When the setup is completed,
Then a training session is conducted to familiarize the team with SonarQube’s functionalities and best practices.
User Story
As a developer, I want to integrate SonarQube into our CircleCI pipeline, So that we can ensure our TypeScript codebase maintains a high standard of quality and meets the minimum test coverage threshold of 80%.
Definition of Done
SonarQube is successfully integrated into the CircleCI pipeline, and configuration files (e.g.,
sonar-project.properties,.circleci/config.yml) are properly set up and committed to the project repository.Testing tools are configured to generate coverage reports in lcov format. Coverage reports are automatically combined and fed into SonarQube during the CI process without manual intervention.
The custom quality profile for TypeScript is active and configured in SonarQube. Quality gates are set up to ensure that no code with less than 80% coverage is merged into the main branch.
Documentation detailing the SonarQube and CircleCI integration, configuration steps, how to interpret SonarQube reports, and how to resolve issues flagged by quality gates is completed and accessible to all team members.
All sensitive data, including access tokens and credentials, are securely stored using CircleCI's environment variables or secret management features.
Acceptance Criteria
AC1.1:
Given that the team requires a code quality analysis tool, When they access the SonarQube server, Then they should find it properly configured and accessible.
AC1.2:
Given the need for secure integration with our CI/CD pipeline, When the team attempts to connect to SonarQube, Then they should be able to use secure credentials and permissions already set.
AC2.1: => new story
Given a project repository, When a developer commits to the main branch, Then a CircleCI job should trigger that includes SonarQube scanning steps.
AC2.2: => new story
Given the CI/CD pipeline in CircleCI, When SonarQube scans are run, Then caching is used effectively to optimize build times for Node.js dependencies.
AC3.2: => new story
Given individual lcov coverage reports, When the CI process runs, Then these reports are combined into a single lcov file before SonarQube analysis.
AC3.1: => AC for vitest and cyprus test story
Given multiple testing tools are used in the project (e.g., Vitest, cypress), When tests are executed, Then each tool should generate coverage reports in lcov format.
AC4.1:
Given a TypeScript project, When configuring SonarQube, Then the sonar-project.properties file should be specifically set up for TypeScript including necessary exclusions and inclusions.
AC5.1:
Given a need to maintain high code quality, When a developer pushes new code, Then the SonarQube quality gate should only pass the code if it has 80% or more coverage.
AC5.2:
Given the active SonarQube quality gates, When analyzing the code for quality metrics, Then the gates should also consider bugs, code smells, and vulnerabilities.
AC6.1:
Given the new setup of SonarQube in CircleCI, When team members look for guidance, Then they should find complete documentation on the setup and troubleshooting.
AC6.2:
Given the complexity and newness of the integrated tools, When the setup is completed, Then a training session is conducted to familiarize the team with SonarQube’s functionalities and best practices.
Links