[CI/CD] GitHub Actions와 AWS CodeDeploy를 활용한 SpringBoot 프로젝트 EC2에 자동 배포 적용 - CI편

CI(Continuous Integration): 지속적 통합

졸프 중 수많은 구글링과 함께 나홀로 CI/CD 시도하기..

 

1. Repository의 Actions 창에서 Java with Gradle 선택

Spring Boot, Gradle 프로젝트를 자동 배포하고 싶기 때문에 GitHub Actions에서 Java with Gradle 선택

 

---

2. 자동으로 생성되는 gradle.yml(CI.yml) 템플릿 수정

main 또는 dev 브랜치에 pull request시 아래의 작업이 실행됨

- jobs: 실행될 작업들

name: Java CI with Gradle

on:
  pull_request:
    branches: [ "main", "dev" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'

    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@417ae3ccd767c252f5661f1ace9f835f9654f2b5 # v3.1.0

    - name: Grant Execute Permission for Gradlew #파일 실행 권한 주기
      run: |
        chmod +x ./gradlew
      shell: bash

    - name: Build with Gradle Wrapper
      run: ./gradlew clean build --exclude-task test #테스트 없이 빌드

 

 기존 코드에 변경 사항을 머지했을 때 문제가 없을 지는 빌드 성공 여부를 통해 알 수 있다. 따라서, 지속적 통합에서는 빌드하는 과정을 작업으로 설정한 것이다.

 실제 빌드를 하는 ./gradlew clean build 뒤의 --exclude-task test는 테스트 없이 빌드하는 것을 의미한다. 해당 코드를 붙이지 않으면, TestApplication에서 오류가 발생하는 것을 확인할 수 있는데, 본 프로젝트에서는 불필요하기 때문에 테스트 제외하고 빌드하도록 해당 코드를 추가해주었다.

 

와!! 끝났나??

아뇨!!! 위 작업만 한 경우에는

물론 pull request를 생성하면 해당 작업이 잘 실행되기는 하지만, 성공 여부에 관계 없이 merge pull request를 할 수 있다.

 

그렇게 되면..

결과를 확인하기 전에 merge를 해버렸는데 사실은 빌드 작업이 실패였을 때,

큰일이 나죠... 🤯

 

그래서 결과를 확인 해야만 머지할 수 있도록 막아볼 겁니다!!

 

---

3. 위에서 설정한 workflow가 실패한 경우 merge 할 수 없도록 branch rule 추가

깃헙에는 브랜치에 규칙을 설정할 수 있는 기능이 제공된다.

 

팀플에서는 코드 리뷰가 하나라도 있어야 머지할 수 있도록 할 수도 있고,
동아리에서는 미션 제출 후 운영진이 아닌 경우 머지할 수 없도록 막을 수도 있다.

 

중요한 브랜치를 보호하는 데에 사용되는 것이 목표라고 생각한다.

 

1) Repository > Settings > Branches > Add rule

 

2) Branch name pattern에 workflow를 적용할 브랜치명 입력

개발 중에는 main 브랜치가 아닌 dev에 많이 적용하고, main은 최종 배포용으로 사용하지만 짧고 빠르게 진행한 프로젝트라 main에 바로 적용했다.

3) Require status checks to pass before merging > Require branches to be up to date before merging 체크

입력하는 부분에 CI.yml에서 작성한 ‘해야 하는 작업’을 검색하고 뜨는 걸 선택해준다.

이 때, 해야 하는 작업이란 jobs: 아래 적은 이름이다.

만약 이 코드가 아래와 같았다면 ‘go’를 입력하면 된다.

jobs:
    go:

선택을 하고 나면 하단에 GitHub Actions에 등록되어 있는 작업임이 표시되는 것을 확인할 수 있다.

이외에도 main에 머지하기 전에 pr을 필수로 지정하거나, 한 명이라도 코드 리뷰를 남긴 경우에만 머지할 수 있도록 하는 등 rule에서 굉장히 많은 조건을 설정할 수 있다. 팀원과의 협의 하에 규칙을 정해두는 것도 좋다.

 

오!! 이제 됐나요?

넹!!!! 확인하러 갑시다 :)

 

---

4. pull request 생성시 workflow 성공 여부에 따른 merge 버튼 활성화 확인

이제 pull request를 생성하면

build 과정을 작성한 actions workflow가 실행되고, 이 workflow가 성공하지 않으면 merge 할 수 없도록 막혀있다.

 

해당 workflow를 실행하는 동안 오류가 발생하지 않고 모든 과정이 성공적으로 마무리되면, 아래와 같이 merge pull request 버튼이 활성화 된다.

실행된 workflow의 과정, 결과, 오류난 지점 등은 Actions 탭에서 확인할 수 있다.

 

한 가지 더..! - workflow 이전에, 코드에 충돌이 있으면?

workflow의 성공 여부를 확인하기 앞서 코드에 충돌이 있는 경우에는 일반적인 경우와 같이 빨간색으로 머지가 불가능하다고 표시된다. 이 때에는 우선 충돌을 resolve하면 된다.

resolve하는 즉시 해당 workflow가 다시 실행될 것이며, 그 이후의 과정은 위에서와 같다.

 

 

 

👇🏻 CD편 바로가기 👇🏻

[CI/CD] GitHub Actions와 AWS CodeDeploy를 활용한 SpringBoot 프로젝트 EC2에 자동 배포 적용 - CD편