🌈 문제상황
현재 프로젝트 진행 과정은 아래와 같다.
1. 이슈/pr 생성
2. 개발
3. commit & push
4. pr리뷰 및 병합
개발을 진행하면서 단위 테스트와 통합 테스트의 개수가 많아져 100개가 넘어가기 시작하였다.
그래서 이슈/pr을 생성하고 개발이 완료된 후에 반드시 직접 테스트를 돌려볼 필요가 있었다.(만약 제대로 동작하지 않는 테스트가 있다면 개발 진행 중에 잘못된 코드가 있을 테니까!)
그러나 역시.. 사람이 직접 수동으로 테스트하려니까 까먹고(?) 테스트를 돌리지 않은 상태로 commit & push를 진행하기도 했고,
심지어 테스트가 제대로 돌아가지 않는데도 pr후 병합을 해버리는 경우도 발생했다.
(최신 pull 받고 테스트 돌렸는데 테스트가 실패해요...ㅠ)
그래서 이러한 수동 테스트를 자동화시킬 필요성이 있었고, 그동안 적용해 보기로 마음만(?) 먹었던 CI(Continuous Integration)를 적용해보기로 하였다.
(세트 상품(?) CD는 아직 배포를 진행하지 않아서 추후에 배포 진행 시에 해보려구 한다)
🌈 Github Actions를 활용한 CI 적용하기
찾아보니 CI/CD도구에는 아래와 같이 여러 가지가 존재했다.(후덜덜..)
- Github Actions
- Jenkins
- Circle CI
- Travis CI
어떤 도구를 사용하든 CI를 구축하는 데에는 큰 문제가 없었고, 아래와 같은 이유로 Github Actions를 사용하기로 하였다.
1. 무료(프로젝트에 적합하다고 판단)
2. 빌드를 위한 별도의 서버가 필요하지 않다(Github에서 제공해 주는 서버로 빌드처리)
3. 문법이 간단하고 빠르게 배우고 적용하기 쉽다.(구축시간이 빠르다)
그렇게 해서 완성된 CI 스크립트는 아래와 같다.
.gihub/workflows 폴더 하위에 deploy.yml이라는 파일을 만들어 스크립트를 작성해 준다.
name: Run Test
on:
pull_request:
branches: [develop]
push:
branches: [develop]
workflow_dispatch:
permissions:
contents: read
jobs:
Run_Test:
runs-on: ubuntu-22.04
services:
mysql:
image: mysql:8.0
env:
MYSQL_ROOT_PASSWORD: admin
MYSQL_DATABASE: devtoon_db
MYSQL_USER: local_user
MYSQL_PASSWORD: local_password
ports:
- 3307:3306
steps:
- name: 레포지토리를 체크아웃 합니다.
uses: actions/checkout@v4
- name: JDK 21 설치합니다.
uses: actions/setup-java@v4
with:
java-version: '21'
distribution: 'temurin'
- name: gradlew 권한을 부여합니다.
run: chmod +x ./gradlew
- name: 테스트용 application.yaml을 작성합니다.
run: |
mkdir -p src/test/resources
echo "${{ secrets.APPLICATION_TEST_YML }}" | base64 --decode > src/test/resources/application.yaml
- name: Gradle을 통해 빌드합니다.
run: ./gradlew build
- name: 테스트를 실행합니다.
run: ./gradlew clean test
기본 동작 순서는 레포지토리를 체크아웃하고 java설치, gradle을 통한 테스트 수행이다.
그 과정에서 테스트를 위한 mysql을 실행시켜주고 있고, test를 위한 application.yaml은 github의 secrets기능을 이용해서 따로 관리해주고 있기 때문에, 빌드용 서버에 지접 작성해주고 있다.
짠! 이제 아래처럼 pr을 생성하니까 테스트 스크립트가 동작!
🌈 마무리
이렇게 아주 간단히(?) 스크립트 작성을 통해서 CI를 경험해 볼 수 있었다.
CI 스크립트를 통해서 이슈에 대한 개발을 진행하고, pr을 생성하면 CI 테스트가 동작한다.
또한 pr생성/리뷰를 마친 후 develop 브랜치에 병합하는 과정에서 한 번 더 CI 테스트가 동작한다.
프로젝트가 더욱 커지고, 개발자가 직접 수동으로 해야 하는 작업이 많아질수록 자동화의 중요성은 커질 것이라고 생각한다.
CI를 경험해 볼 수 있어서 좋았고, 추후에 배포를 진행한다면 CD과정도 진행해 볼 것 같다.
(이제 적어도 develop에서 최신 pull 받은 이후 테스트가 동작하지 않는 일은 이제 없겠지..?)
'프로젝트 > 데브툰' 카테고리의 다른 글
[프로젝트] @Async를 알아보자(feat. 빈 후처리기) (0) | 2024.05.08 |
---|---|
[프로젝트] @Async를 알아보자(feat. Spring과 Proxy) (0) | 2024.05.07 |
[프로젝트] @Async를 알아보자(feat. Spring AOP) (0) | 2024.05.06 |
[프로젝트] 비동기 프로그래밍 적용해보기 (0) | 2024.05.01 |
[프로젝트] 프로젝트 목표 및 기획 (0) | 2024.04.30 |