지난 시간에는 젠킨스 파이프라인의 기초를 배웠습니다. 이번 시간에는 CI 파이프라인을 완성하는 데 필요한 인수 테스트(UAT) 와 도커 레지스트리, 그리고 BDD/TDD 의 개념까지 정리했습니다.
1. 인수 테스트 (UAT; User Acceptance Test)
인수 테스트는 요구사항대로 기능이 구현되었는지를 확인하는 과정입니다. CI/CD 파이프라인을 완성하기 위해서는 이 인수 테스트 역시 자동화되어야 합니다.
그러나 인수 테스트는 다른 테스트에 비해 자동화하기가 특히 어렵습니다. 그 이유는 다음과 같습니다.
| 어려운 요인 | 설명 |
|---|---|
| 사용자 참여 | 기술적·비기술적 요구사항의 최종 확인은 실사용자여야 합니다 |
| 의존성 통합 | 테스트할 애플리케이션은 모든 의존성을 포함하여 실행해야 합니다 |
| 스테이징 환경 | 프로덕션 환경과 동일한 스테이징 환경에서 이루어져야 합니다 |
| 애플리케이션 동일성 | 한 번만 빌드하여 프로덕션에서와 동일한 바이너리를 이용해야 합니다 |
| 릴리스 준비 | 인수 테스트를 통과한 애플리케이션은 즉시 릴리스 준비가 되어야 합니다 |
이러한 문제들을 해결하기 위해 도커 레지스트리를 구성한 뒤 애플리케이션 이미지를 빌드 및 푸시하고, UAT 프레임워크를 적용하는 방식으로 자동화를 진행합니다.
2. Artifact Repository
Artifact Repository 는 파이프라인의 모든 단계에서 동일한 바이너리가 사용되는 것을 보장함으로써 지속적 인도 프로세스에서 매우 중요한 역할을 합니다.
버전 관리, 접근 제어 등의 기능을 갖추어 소프트웨어 개발 산출물을 발행하거나 인출할 수 있는 저장소 및 관리 기법이 필요합니다.
3. Docker Registry
Docker Registry 는 컨테이너화된 소프트웨어의 산출물인 도커 이미지를 관리할 수 있는 리포지토리입니다.
레지스트리 방식은 크게 두 가지로 나뉩니다.
| 방식 | 설명 |
|---|---|
| 클라우드 방식 | Docker Hub, 상용 클라우드에서 제공하는 서비스를 이용합니다 |
| 자체 호스팅 방식 | 사내 네트워크 외부에 소프트웨어 보관을 금지하는 정책이 있는 경우 유일한 해결 방법입니다. 단, 직접 관리해야 하는 부담과 접근 제어·인증서 설정 등의 번거로운 작업이 수반됩니다 |
4. 데이터 볼륨과 SSL 인증서
레지스트리를 안정적으로 운영하기 위해 볼륨과 SSL 인증서 설정이 필요합니다.
데이터 볼륨
컨테이너나 포드가 사멸하더라도 레지스트리에 저장된 데이터를 유지할 수 있도록, 호스트의 디렉토리를 레지스트리에 볼륨으로 공유합니다.
- PV(Persistent Volume) 를 정의하고 PVC(Persistent Volume Claim) 를 설정하여 레지스트리 서버 컨테이너에서 이용하도록 볼륨을 마운트합니다.
- 실제 개발 환경에서는 저장 장소를 마련해 두고 주기적으로 백업하는 방법을 사용합니다.
# deployment, service, pv, pvc를 모두 하나의 파일에 담아 한 번에 적용합니다
kubectl apply -f registry.yamlSSL 인증서
자가 서명된 인증서를 발급하여 레지스트리 서버에 설치합니다. 실제 운용 환경에서는 CA(Certificate Authority) 로부터 발급받은 인증서를 주기적으로 갱신하여 사용해야 합니다.
5. 젠킨스 파이프라인에서의 인수 테스트 흐름
젠킨스가 인수 테스트를 포함한 전체 CI 파이프라인을 자동화하는 흐름은 다음과 같습니다.
1. 개발자가 변경한 코드를 GitHub에 푸시
2. Jenkins가 변경을 감지하고 코드를 인출해 빌드 시작, 단위 테스트 수행
3. Jenkins가 빌드를 완료하여 도커 이미지를 생성
4. Jenkins가 생성한 이미지를 레지스트리로 푸시
5. Jenkins가 스테이징 환경을 구성하고 도커 컨테이너 실행
6. 스테이징 환경의 도커 호스트가 이미지를 Pull하여 컨테이너를 실행
7. Jenkins가 스테이징 환경에서 실행 중인 애플리케이션을 대상으로 인수 테스트를 실행인수 테스트 파이프라인 스테이지
pipeline {
agent any
stages {
stage('Package') {
steps { /* 애플리케이션 빌드 */ }
}
stage('Docker Build') {
steps { /* 도커 이미지 빌드 */ }
}
stage('Docker Push') {
steps { /* 레지스트리에 이미지 푸시 */ }
}
stage('Acceptance Test') {
steps { /* 스테이징 환경에서 인수 테스트 실행 */ }
}
}
}테스트 자동화를 위해 리포지토리에 Dockerfile 과 acceptance_test.sh 를 추가합니다. 그리고 기존 파이프라인에서 Poll SCM 옵션을 잠시 끄고 임시 파이프라인 아이템을 새로 생성하여, 지금까지 구성한 단계가 성공적으로 동작하는지 확인합니다.
6. 사용자 대면 테스트 — BDD와 Cucumber
REST API의 경우 curl 을 이용한 테스트로도 어느 정도 블랙박스 테스트가 가능합니다. 하지만 일반적인 경우에는 사용자와 함께 작성하고 사용자가 이해할 수 있는 테스트 방법이 필요합니다.
BDD (Behavior-Driven Development)
사용자가 인수 기준을 제시하면, 개발자는 픽스처(Fixture) 또는 스텝 정의(Step Definition) 라고 부르는 사용자 친화적인 DSL과 프로그래밍 언어를 통합해 테스트를 작성합니다.
이를 도와주는 대표적인 도구는 다음과 같습니다.
- Cucumber — 비기술자도 이해할 수 있는 Gherkin 문법으로 테스트 시나리오를 작성합니다
- Selenium — 브라우저를 자동으로 조작하여 UI 기반의 인수 테스트를 수행합니다
7. TDD (Test-Driven Development)
인수 테스트는 기술보다 사람이 중심입니다. 소프트웨어 개발 수명 주기 중 언제 테스트를 작성해야 할지 고민될 때, TDD는 인수 테스트에 특히 적합한 방법론입니다.
- 인수 기준 사양을 먼저 작성합니다.
- 인수 테스트 통과를 기능 구현 완료로 간주합니다.
- 이슈 추적 도구의 요청 티켓에 기능 사양을 첨부하는 방식으로 관리합니다.
