CI/CD : 테스트 실패시, Push 안되게 하기
2025. 3. 9. 22:25ㆍ개발
서비스 품질을 높이기 위해선 안정적인 테스트 과정이 필수적이다. 그러나 개발 과정에서 테스트가 실패했음을 인지하지 못하고 코드를 병합(Merge)하거나 배포하면 심각한 문제로 이어질 수 있다. 이번에 프로젝트에서 경험한, Gradle과 GitHub Actions를 활용한 CI 환경 구축을 통해 안정성을 높인 경험을 정리해본다.
🚩 테스트 실패, 간과하면 큰일난다
테스트 실패를 놓친 채로 코드가 병합되면 서비스가 정상적으로 동작하지 않을 수 있고, 이를 되돌리는 과정은 추가적인 시간과 노력이 필요하다. 이를 예방하기 위해 프로젝트에서는 다음과 같은 문제를 해결하고자 했다.
- 개발자가 로컬 환경에서 테스트를 수행하지 않고 push하는 경우
- Pull Request(PR) 과정에서 테스트 실패 여부가 확인되지 않아 코드 리뷰 과정이 불편해지는 경우
🛠️ Gradle과 GitHub Actions로 테스트 자동화하기
이런 문제를 방지하기 위해 GitHub Actions를 사용하여 Gradle 테스트를 자동화하는 파이프라인을 설정했다.
- 개발자가 코드를 push 후 PR하면 GitHub Action이 자동으로 테스트를 실행한다.
- 테스트가 실패하면 GitHub Action에서 해당 PR에 실패를 알리고, merge가 불가능하도록 설정한다.
- 개발자는 GitHub에서 즉시 테스트 실패를 확인하고, 문제를 수정한 후 다시 push한다.
- GitHub Action이 다시 테스트를 수행하며 성공 시에만 merge 버튼이 활성화된다
이 과정은 다음과 같은 GitHub Actions 설정으로 구현했다.
name: test
on:
push:
branches: [ develop ]
pull_request:
branches: [ develop ]
workflow_dispatch:
jobs:
test:
runs-on: ubuntu-latest
services:
mongo:
image: mongo:latest
ports:
- 27017:27017
options: --health-cmd="mongosh --eval 'db.adminCommand(\"ping\")'" --health-interval=10s --health-timeout=5s --health-retries=5
steps:
- uses: actions/checkout@v3
- name: JDK 17 설치
uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
- name: secret 설정 파일(yml) 추가
run: |
cd ./src/main/resources
touch ./application-secret.yml
echo "${{ secrets.APPLICATION_SECRET }}" > ./application-secret.yml
- name: firebase_service_key.json 구성
run: |
cd ./src/main/resources
touch ./firebase_service_key.json
echo "${{ secrets.FCM_KEY }}" > ./firebase_service_key.json
- name: firebase_service_key.json 파일 생성
uses: jsdaniell/create-json@1.1.2
with:
name: "firebase_service_key.json"
json: ${{ secrets.FCM_KEY }}
- name: JSON 파일 이동
run: |
mv ./firebase_service_key.json ./src/main/resources/firebase_service_key.json
- name: Gradle 권한 허용
run: chmod +x gradlew
- name: PR 및 PUSH 전, 테스트 확인
run: ./gradlew test
env:
MONGO_HOST: localhost
MONGO_PORT: 27017
✅ CI로 얻은 긍정적 변화
- 안정적인 코드 관리: 테스트 실패한 코드가 실수로 병합되는 일이 사라졌다.
- 빠른 피드백: 개발자가 PR을 올린 즉시 GitHub에서 테스트 결과를 확인할 수 있어 개발 속도가 빨라졌다.
- 협업 효율 증가: 코드 리뷰 과정이 더 신뢰할 수 있고 효율적으로 이루어졌다.
🌟 앞으로 더 나아갈 방향
테스트 과정 외에도 추가적인 코드 품질 관리 도구(Lint, SonarQube 등)와의 통합, 배포 단계와 연계하여 안정성을 더욱 강화할 계획이다. 이번 경험을 통해 GitHub Actions와 Gradle의 조합이 코드 품질과 협업 효율성을 동시에 높여준다는 점을 체감하게 되었다.
'개발' 카테고리의 다른 글
[트러블 슈팅] 테스트 실행 시간이 너무 길어요! (0) | 2025.03.25 |
---|---|
배포 오류 : Asciidoctor 빌드 오류(asGemPath()) (0) | 2025.03.09 |
CI/CD : Github Actions를 이용한 배포 자동화 (0) | 2025.03.09 |
Mock : 모의(대역) 객체로 테스트하기 (0) | 2025.03.08 |
테스트 범위와 종류 : 단위 테스트, 통합 테스트 (0) | 2025.03.08 |