Operations Checklist
This chapter defines the detailed checklist for the operations area of TQS-S/W certification. The operations checklist consists of 3 areas: configuration management, CI/CD, and testing standards. Each item is classified as mandatory (O), recommended (R), or optional (S), with the verification method specified.
32.4.1. Configuration Management
The configuration management checklist verifies standards compliance for Git-based source code version control, branch strategy, commit conventions, and PR operations.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 1 | GitHub Flow branch strategy is applied | O | Branch list and operational history verification |
| 2 | Commit messages are written in Conventional Commits format | O | Commit log verification |
| 3 | PR template is included in the project | O | Verify .github/PULL_REQUEST_TEMPLATE.md file existence |
| 4 | A minimum of 1 PR reviewer is assigned | O | PR history verification |
| 5 | .gitignore file conforms to TQS standards | O | .gitignore file content verification |
| 6 | Semantic Versioning (SemVer) is applied | O | Tag and release history verification |
| 7 | Protection rules are configured on the main branch (direct push prohibited) | R | GitHub repository settings verification |
| 8 | GPG or SSH signing is applied to commits | S | Commit log signature verification |
Configuration management is the foundation for systematically managing a project's change history. The GitHub Flow branch strategy provides a simple yet effective workflow, and Conventional Commits serves as the basis for automated changelog generation and version management.
32.4.1.1. Configuration Management Verification Detailed Criteria
Compliance with the GitHub Flow branch strategy is determined based on the following criteria.
- The
mainbranch must always be maintained in a deployable state. - Feature development must be performed on feature branches branched from
main. - Feature branches must be merged into
mainthrough PRs; direct pushes are not permitted.
Compliance with Conventional Commits is verified based on the most recent 50 commits. A pass is granted when 90% or more of commit messages follow the Conventional Commits format (feat:, fix:, docs:, refactor:, etc.).
32.4.2. CI/CD
The CI/CD checklist verifies the configuration of the CircleCI-based continuous integration and deployment pipeline.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 9 | CircleCI pipeline is configured | O | Verify .circleci/config.yml file existence |
| 10 | Lint verification step is included in the pipeline | O | Verify lint step in CircleCI configuration file |
| 11 | Test execution step is included in the pipeline | O | Verify test step in CircleCI configuration file |
| 12 | Build step is included in the pipeline | O | Verify build step in CircleCI configuration file |
| 13 | All of the last 5 builds are in success state | O | CircleCI build history verification |
| 14 | Security scan step is included in the pipeline | R | Verify security scan step in CircleCI configuration file |
| 15 | Deployment automation is implemented | R | Verify deployment step in CircleCI configuration file |
| 16 | Pipelines are separated by environment (dev / staging / prod) | R | Verify workflows in CircleCI configuration file |
CI/CD is the core infrastructure that continuously verifies code quality and ensures deployment stability. The pipeline must include a minimum of 3 mandatory steps: lint verification, test execution, and build.
32.4.2.1. CI/CD Verification Detailed Criteria
CircleCI pipeline verification is performed based on the following criteria.
- The
.circleci/config.ymlfile must exist at the project root. - Each pipeline step (lint, test, build) must be independently executable.
- Pipeline execution time of 15 minutes or less is recommended.
- Build history is verified through the CircleCI dashboard or API.
32.4.3. Testing Standards
The testing standards checklist verifies the backend testing framework, writing patterns, coverage criteria, and test isolation level.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 17 | JUnit 5 is used as the test framework | O | Verify dependencies in pom.xml |
| 18 | Tests are written using the Given-When-Then pattern | O | Test code review |
| 19 | Line coverage of 80% or above is achieved | O | JaCoCo report verification |
| 20 | Branch coverage of 70% or above is achieved | O | JaCoCo report verification |
| 21 | Each test is independently executable (no dependencies between tests) | O | Test code review |
| 22 | Test method names clearly express the test intent | O | Test code review |
| 23 | Testcontainers is used for integration testing | R | Verify dependencies in pom.xml and test code |
| 24 | Test data is managed independently per test (no shared data) | R | Test code review |
| 25 | Boundary value tests are included | R | Test code review |
Testing standards are a core area that ensures code reliability and maintainability. JUnit 5 and the Given-When-Then pattern ensure test readability and structure, and coverage criteria quantitatively verify test sufficiency.
32.4.3.1. Testing Verification Detailed Criteria
Test coverage is measured based on JaCoCo reports. The following rules are applied when calculating coverage.
- Auto-generated code (jOOQ codegen, etc.) is excluded from coverage calculation.
- Configuration classes (
@Configuration) may be excluded from coverage calculation. - Simple data objects such as DTOs and VOs may be excluded from coverage calculation.
Compliance with the Given-When-Then pattern is verified through manual review. The structure of test methods must be clearly separated into preparation (Given), execution (When), and verification (Then) phases.
32.4.4. Item Summary
The total number of items and distribution by classification for the operations checklist are as follows.
| Area | Mandatory (O) | Recommended (R) | Optional (S) | Total |
|---|---|---|---|---|
| Configuration Management | 6 | 1 | 1 | 8 |
| CI/CD | 5 | 3 | 0 | 8 |
| Testing Standards | 6 | 3 | 0 | 9 |
| Total | 17 | 7 | 1 | 25 |
The operations checklist consists of a total of 25 items. All 17 mandatory items must be met to obtain Basic certification, and the compliance rate of the 7 recommended items determines whether the Advanced or Premier certification grade is achieved. The 1 optional item is not included in the certification grade calculation.
32.4.5. Operations Verification Notes
The following points must be observed when verifying the operations checklist.
- Configuration management items are verified by directly inspecting the project's GitHub repository. For private repositories, read access must be granted to the TQS Committee.
- CI/CD items are verified by examining both the pipeline configuration file and execution history. If only the configuration file exists without actual execution history, the item is judged as non-compliant.
- Testing standards items are verified through a combination of automated verification (coverage metrics) and manual review (test code quality).
- Commit history and PR history are verified based on activity within the most recent 3 months.