1. Introduction
This question evaluates your understanding of entry criteria within a DevOps delivery pipeline, especially the conditions required before merging code into the test branch.
이 문제는 DevOps 딜리버리 파이프라인에서 단계 시작 조건(Entry Criteria)이 무엇인지 이해하고 있는지 평가합니다. 특히, “test” 브랜치로 코드 머지 전에 충족되어야 하는 조건을 다룹니다.
2. Key Concepts
✔ Understanding Entry Criteria in DevOps (EN/KR)
Entry Criteria are conditions that must be satisfied before moving into the next stage of the pipeline.
시작 기준(Entry Criteria)은 파이프라인의 다음 단계로 이동하기 위해 반드시 충족되어야 하는 조건입니다.
For step (2): Submit code → Version control → Merge into “test” branch The code must be in a state that is safe to commit.
2단계(코드 제출 및 test 브랜치 머지)에서는 코드가 저장소에 제출되기 전에 안전하고 문제없는 상태여야 합니다.
✔ Static Analysis Before Commit
- Detects coding rule violations
- Prevents severe issues before merging
- Can be automated in pre-commit hooks
- 코딩 규칙 위반과 결함을 조기 발견
- 문제가 있는 코드가 test 브랜치로 들어가는 것을 방지
- pre-commit hook 형태로 자동화 가능
3. Practice Question
❓ Question
Which of the following is BEST suited to be the entry criterion for step (2) of the DevOps pipeline?
- a) Static analysis returns no high severity warnings for the submitted code
- b) System version control reports no conflicts when merging code into the “test” branch
- c) Component tests are compiled and ready to be executed
- d) Statement coverage is at least 80%
✅ Correct Answer: a)
📘 Explanation (EN/KR)
a) Correct.
Static analysis can—and should—be executed before committing code to the repository.
This ensures the code is clean and safe before merging.
정적 분석은 코드 제출 전에 수행할 수 있으며, 제출 전 코드 상태를 검증하는 데 매우 적합합니다. 따라서 2단계 시작 조건에 가장 적합한 선택지입니다.
b) Not correct.
Merge conflict detection happens after attempting the merge, so it cannot be an entry criterion for step (2).
머지 충돌은 머지를 시도한 이후에만 알 수 있으므로, 2단계 시작 기준이 될 수 없습니다.
c) Not correct.
This is an entry criterion for step (3), where component testing takes place.
컴포넌트 테스트 준비(컴파일 완료)는 3단계의 시작 기준입니다.
d) Not correct.
Coverage targets (80% or more) are typically exit criteria for testing in step (3).
커버리지 목표(예: 80%)는 보통 3단계 테스트 종료 기준에 속합니다.
📊 Summary Table
| Option | Correct? | Reason (EN) | Reason (KR) |
|---|---|---|---|
| a | ✔ Entry | Static analysis is done before commit | 정적 분석은 커밋 전에 수행 가능 |
| b | ✘ | Merge conflicts appear after merging | 머지 후에만 충돌 여부 확인 가능 |
| c | ✘ | Component test readiness is for step (3) | 컴포넌트 테스트 준비는 3단계 기준 |
| d | ✘ | Coverage targets are exit criteria | 커버리지는 종료 기준 |
4. Summary & Call to Action
In DevOps pipelines, entry criteria ensure each step begins with a stable foundation. Static analysis checks are ideal pre-commit gates and prevent faulty code from entering shared branches.
DevOps 파이프라인에서 시작 기준은 각 단계가 안정적인 상태에서 진행되도록 보장합니다. 정적 분석은 코드 제출 전에 수행되어 문제 있는 코드가 공유 브랜치로 들어가는 것을 방지합니다.
Related: More ISTQB Posts