Github Labels와 함께하는 CI/CD 리팩토링

🤔 문제점 및 목적

👀 해결 방법

🐾 적용 과정

👀 테스트

📄 관련 문서

문제점 및 목적

아래 사진은 기존의 CI/CD 플로우입니다.

설명을 덧붙이자면 ‘main’ 브랜치로 push가 되면 Github Action의 Trigger Event가 발생하게됩니다.

이벤트 발생 후엔 빌드, 테스트, S3 업로드 등이 workflow.yml에 작성해 둔 스크립트대로 동작하게 되는데

이 때 커밋 설명 중 맨 윗 줄에 ‘[USER]’ 와 같은 문자로 배포하고자하는 서비스에 대한 분기 포인트를 제공합니다.

문자열을 파싱해 분기점을 나눠 해당 서비스를 배포하기 위한 AWS CodeDeploy 배포 그룹에 요청을 보내게 됩니다.

그 후엔 CodeDeploy와 AutoScaling을 이용해 deploy.sh를 실행시키며 Blue/Green 무중단 배포를 하게 됩니다.

deploy.sh는 S3에서 받아온 jar파일에 프로필 인자를 이용해 live서버와 dev서버를 실행시킵니다.

서버를 안정적으로 운영하기 위해선 live서버와 dev서버를 분리시키는 것이 맞다고 판단했고 기존의 Trigger Event를 발생시키는 방식에서도 불편함을 느꼈습니다.

또 하나의 문제점은 Git 사용이었습니다.

기존의 Git은 혼자서 사용했기에 Trunk-Based 전략을 채용했고 main과 develop 2개의 브랜치를 사용하였습니다.

하지만 develop에서 작업 후 PR을 생략하고 main에 바로 merge하는게 잦아졌고 Git을 사용하는 의미가 퇴색되었습니다.

PR에 대한 습관을 기르며 추후 다른 백엔드 개발자와 협업을 하기 위한 확실한 Git 사용 전략이 필요하다고 생각했습니다.

정리하자면 제가 개선하고자 하는 부분은 3가지입니다.

휴먼에러가 발생할 수 있는 문자열에 의한 분기 방법과 필요한 서버에만 배포하기 어려운 점

같은 인스턴스에 live, dev 2개의 서버가 동시에 실행되는 점

Git 전략을 제대로 활용하지 않고 있는 점

해결 방법

아래의 사진은 변경하고자 하는 CI/CD 플로우입니다.

Git을 제대로 활용하지 않는 점은 Jira에 Git을 연동해 사용하며 각 티켓마다 생기는 브랜치에서 작업을 한 후

원하는 서버 브랜치에 PR을 날리게되면 무조건 테스트를 거치고 해당 테스트 결과는 PR comment와 슬랙 알람으로 추적이 가능하게 하는 방식으로

Git의 Pull Request와 Github Action의 workflow를 적극 활용하는 방법을 생각하였습니다.

같은 인스턴스에 live와 dev서버가 동시에 실행되는 점과 불편한 분기 방법은 현재 서비스에 맞게끔

우선 인스턴스를 현재 서비스에 맞게 각 서버별로 쪼갠 후 그렇게 생긴 6개의 인스턴스에 대해 각각 배포그룹을 만들고

PR의 Label 기능과 브랜치 이름을 이용해 분기하는 방법을 생각하였습니다.

적용 과정

•

기존의 workflow 스크립트

# Event Trigger
on:
  push:
    branches: [ "main" ]

permissions: read

defaults:
  run:
    working-directory: be

env:
    SERVICE:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    # JDK 설치
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
          java-version: '17'
          distribution: 'corretto'

    # Git pull
    - uses: actions/checkout@v3

     # 변수 등록
    - name: Set variable
      run: echo "SERVICE=$(echo -n "${{ github.event.head_commit.message }}" | cut -d ']' -f1 | cut -c 2- | head -1)" >> $GITHUB_ENV

    # secrets에 application.yml 복사
    - name: Copy application.yml
      run: |
        mkdir ./module-user-api/src/main/resources
        touch ./module-user-api/src/main/resources/application.yml
        echo "${{ secrets.USER_APPLICATION }}" > ./module-user-api/src/main/resources/application.yml
        mkdir ./module-business-api/src/main/resources
        touch ./module-business-api/src/main/resources/application.yml
        echo "${{ secrets.BUSINESS_APPLICATION }}" > ./module-business-api/src/main/resources/application.yml
        mkdir ./module-admin-api/src/main/resources
        touch ./module-admin-api/src/main/resources/application.yml
        echo "${{ secrets.ADMIN_APPLICATION }}" > ./module-admin-api/src/main/resources/application.yml

    # secrets에 ApplePrivateKey.p8 복사
    - name: Copy ApplePrivateKey.p8
      run: |
        mkdir ./module-user-api/src/main/resources/key
        touch ./module-user-api/src/main/resources/key/ApplePrivateKey.p8
        echo "${{ secrets.APPLE_PRIVATE_KEY }}" > ./module-user-api/src/main/resources/key/ApplePrivateKey.p8
        mkdir ./module-business-api/src/main/resources/key
        touch ./module-business-api/src/main/resources/key/ApplePrivateKey.p8
        echo "${{ secrets.APPLE_PRIVATE_KEY }}" > ./module-business-api/src/main/resources/key/ApplePrivateKey.p8
        mkdir ./module-admin-api/src/main/resources/key
        touch ./module-admin-api/src/main/resources/key/ApplePrivateKey.p8
        echo "${{ secrets.APPLE_PRIVATE_KEY }}" > ./module-admin-api/src/main/resources/key/ApplePrivateKey.p8

    # Gradle 권한 부여
    - name: Grant execute permission for Gradle
      run: chmod +x ./gradlew

     # Gradle로 빌드 실행
    - name: Run build with Gradle
      run: ./gradlew build -x test

    # 서비스에 따라 deploy 폴더에 jar, appspec.yml, deploy.sh 복사
    - name: Copy And Zip files To Directory
      if: ${{ env.SERVICE == 'USER' }}
      run: |
        mkdir ./deploy
        cp ./module-user-api/build/libs/*.jar ./deploy/
        cp ./appspec.yml ./deploy/
        cp ./scripts/deploy.sh ./deploy/
        cp ./agents/*.jar ./deploy/
        zip -r -qq -j ./${{env.SERVICE}}-$GITHUB_SHA.zip ./deploy

    - name: Copy And Zip files To Directory
      if: ${{ env.SERVICE == 'BUSINESS' }}
      run: |
        mkdir ./deploy
        cp ./module-business-api/build/libs/*.jar ./deploy/
        cp ./appspec.yml ./deploy/
        cp ./scripts/deploy.sh ./deploy/
        cp ./agents/*.jar ./deploy/
        zip -r -qq -j ./${{env.SERVICE}}-$GITHUB_SHA.zip ./deploy

    - name: Copy And Zip files To Directory
      if: ${{ env.SERVICE == 'ADMIN' }}
      run: |
        mkdir ./deploy
        cp ./module-admin-api/build/libs/*.jar ./deploy/
        cp ./appspec.yml ./deploy/
        cp ./scripts/deploy.sh ./deploy/
        cp ./agents/*.jar ./deploy/
        zip -r -qq -j ./${{env.SERVICE}}-$GITHUB_SHA.zip ./deploy

    #AWS 인증
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-2

    # deploy.zip S3 업로드
    - name: Upload to AWS S3
      run: aws s3 cp --region ap-northeast-2 ./${{env.SERVICE}}-$GITHUB_SHA.zip s3://gocho-deploy/${{env.SERVICE}}-$GITHUB_SHA.zip

    # User Service Deploy
    - name: User Service Deploy
      if: ${{ env.SERVICE == 'USER' }}
      env:
        aws-access-key-id: ${{ secrets.AWS_S3_ACCESS_KEY }}
        aws-secret-access-key: ${{ secrets.AWS_S3_SECRET_KEY }}
      run: |
        aws deploy create-deployment \
        --application-name Gocho_BE_Spring_Server_CI_CD \
        --deployment-group-name Gocho_BE_User_Deploy \
        --file-exists-behavior OVERWRITE \
        --s3-location bucket=gocho-deploy,bundleType=zip,key=${{env.SERVICE}}-$GITHUB_SHA.zip \
        --region ap-northeast-2

    # Business Service Deploy
    - name: Business Service Deploy
      if: ${{ env.SERVICE == 'BUSINESS' }}
      env:
        aws-access-key-id: ${{ secrets.AWS_S3_ACCESS_KEY }}
        aws-secret-access-key: ${{ secrets.AWS_S3_SECRET_KEY }}
      run: |
        aws deploy create-deployment \
        --application-name Gocho_BE_Spring_Server_CI_CD \
        --deployment-group-name Gocho_BE_Business_Deploy \
        --file-exists-behavior OVERWRITE \
        --s3-location bucket=gocho-deploy,bundleType=zip,key=${{env.SERVICE}}-$GITHUB_SHA.zip \
        --region ap-northeast-2

    # Admin Service Deploy
    - name: Admin Service Deploy
      if: ${{ env.SERVICE == 'ADMIN' }}
      env:
        aws-access-key-id: ${{ secrets.AWS_S3_ACCESS_KEY }}
        aws-secret-access-key: ${{ secrets.AWS_S3_SECRET_KEY }}
      run: |
        aws deploy create-deployment \
        --application-name Gocho_BE_Spring_Server_CI_CD \
        --deployment-group-name Gocho_BE_Admin_Deploy \
        --file-exists-behavior OVERWRITE \
        --s3-location bucket=gocho-deploy,bundleType=zip,key=${{env.SERVICE}}-$GITHUB_SHA.zip \
        --region ap-northeast-2
YAML
복사

위 코드는 기존의 workflow 스크립트입니다.

commit 설명에서 파싱해온 문자열을 통해 if문으로 분기점을 잡기 위해 같은 코드를 3번씩 적는 상황이었습니다.

테스트 또한 CI/CD 과정에서 자동으로 이루어지지 않았고 workflow에 대한 결과도 추적할 수 없었습니다.

이 문제를 해결하기 위해 workflow를 테스트와 배포 2개로 나눌 계획입니다.

•

새로 작성한 Test Workflow

우선 테스트 부분부터 부분부분 별로 설명하며 작성하겠습니다.

name: Test WorkFlow

on:
  pull_request:
    types:
      - opened
    branches:
      - 'live'
      - 'dev'
YAML
복사

이 workflow의 Trigger Event는 main, dev 브랜치에 대한 pull_request로 타입이 ‘opened’일 때만 실행합니다.

즉, 타겟 브랜치에 대한 PR이 작성되면 자동으로 실행되는 스크립트입니다.

env:
  SERVICE:
  SERVER:
YAML
복사

env는 Github Action의 가상 환경에서 사용할 환경변수를 말합니다.

SERVICE와 SERVER는 PR의 Label과 타겟브랜치에서 가져온 타겟서비스와 타겟서버입니다.

jobs:
  Test-Job:
    if: github.event.action == 'opened' && github.event.pull_request.merged == false
    runs-on: ubuntu-latest
    steps:
YAML
복사

jobs는 여러 job을 가질 수 있는데 각 job은 독립된 가상 환경에서 병렬로 실행되는 큰 단위의 태스크입니다.

저는 workflow 자체를 2개로 나눌 것이기 때문에 Test-Job 하나만 작성하였습니다.

if문에 대한 내용은 PR이 요청됐는데 아직 merge되지 않았을 때만 job을 실행하라는 의미이고 runs-on은 job을 실행할 가상 환경을 의미합니다.

마지막 steps는 job 하위의 직렬로 실행되는 작은 단위의 태스크들입니다.

# Git Checkout
- name: Git Checkout
  uses: actions/checkout@v3
YAML
복사

PR 요청을 보낼 브랜치로 checkout 하며 코드를 받아옵니다.

# 환경변수 설정
- name: Set Environment
  run: |
    sudo timedatectl set-timezone 'Asia/Seoul'
    echo "SERVICE=$(echo ${{ github.event.pull_request.labels[0].name }})" >> $GITHUB_ENV
    echo "SERVER=$(echo ${{ github.base_ref }} )" >> $GITHUB_ENV
YAML
복사

위에서 설명한 env.SERVICE와 env.SERVER 환경변수에 값을 넣어주고 시스템 timezone을 바꿔줍니다.

# JDK 설정
- name: Set JDK
  uses: actions/setup-java@v3
  with:
    java-version: '17'
    distribution: 'corretto'

# MySQL 설정
- name: Set MySQL
  run: |
    sudo /etc/init.d/mysql start
    mysql -uroot -proot -e 'SET @@GLOBAL.sql_mode="";'
    mysql -uroot -proot -e 'CREATE DATABASE gocho_test;'
    mysql -uroot -proot gocho_test < be/module-${{env.SERVICE}}-api/src/test/resources/sqls/schema.sql
    mysql -uroot -proot gocho_test < be/module-${{env.SERVICE}}-api/src/test/resources/sqls/data.sql

# Redis 설정
- name: Set Redis
  run: |
    sudo apt-get install redis
YAML
복사

JDK, MySQL, Redis를 세팅해줍니다.

로컬에선 테스트를 위한 더미데이터가 hibernate의 기능으로 SQL이 자동 실행됐었지만

gradle 환경에선 사용할 수 없어서 MySQL 커맨드를 이용해 Schema를 만들고 더미데이터를 주입해줍니다.

또한 Github Action의 ubuntu 가상환경에선 기본적으로 MySQL 8.0이 포함되어있어서 sql_mode로 인한 에러가 발생할 수 있으므로 sql_mode를 지워줍니다.

# application.yml 복사
- name: Copy application.yml
  run: |
    mkdir -p be/module-user-api/src/main/resources && echo "${{ secrets.USER_APPLICATION }}" > be/module-user-api/src/main/resources/application.yml
    mkdir -p be/module-business-api/src/main/resources && echo "${{ secrets.BUSINESS_APPLICATION }}" > be/module-business-api/src/main/resources/application.yml
    mkdir -p be/module-admin-api/src/main/resources && echo "${{ secrets.ADMIN_APPLICATION }}" > be/module-admin-api/src/main/resources/application.yml

# ApplePrivateKey.p8 복사
- name: Copy ApplePrivateKey.p8
  run: |
    mkdir -p be/module-user-api/src/main/resources/key && echo "${{ secrets.APPLE_PRIVATE_KEY }}" > be/module-user-api/src/main/resources/key/ApplePrivateKey.p8
    mkdir -p be/module-business-api/src/main/resources/key && echo "${{ secrets.APPLE_PRIVATE_KEY }}" > be/module-business-api/src/main/resources/key/ApplePrivateKey.p8
    mkdir -p be/module-admin-api/src/main/resources/key && echo "${{ secrets.APPLE_PRIVATE_KEY }}" > be/module-admin-api/src/main/resources/key/ApplePrivateKey.p8
YAML
복사

Github Action의 Secrets에 넣어놨던 properties 파일 등을 받아옵니다.

# Gradle 권한 설정
- name: Grant execute permission for Gradle
  working-directory: be
  run: chmod +x ./gradlew

# Gradle로 테스트 실행
- name: Run test with Gradle
	if: ${{ env.SERVICE != 'all' }}
  working-directory: be
  run: ./gradlew :module-${{env.SERVICE}}-api:test -Duser.timezone=Asia/Seoul

# all 라벨일 경우 Gradle로 모든 모듈 테스트 실행
- name: Run all test with Gradle
  if: ${{ env.SERVICE == 'all' }}
  working-directory: be
  run: ./gradlew test -Duser.timezone=Asia/Seoul
YAML
복사

테스트를 진행하기 위해 gradle을 사용할건데 가상 환경에서 gradle wrapper를 사용하기 위해선 권한 설정이 필요합니다.

테스트를 진행할 땐 인자를 주어 timezone을 설정하고 원하는 모듈에 대한 테스트를 진행합니다.

# 테스트 결과 PR 코멘트로 등록
- name: PR Comment
  uses: EnricoMi/publish-unit-test-result-action@v1
  if: always()
  with:
    files: '**/build/test-results/test/TEST-*.xml'

# 테스트 결과 슬랙 알람
- name: Slack Alarm
  uses: 8398a7/action-slack@v3
  if: always()
  with:
    status: ${{ job.status }}
    author_name: Github Action Test
    fields: repo,message,commit,author,action,eventName,ref,workflow,job,took,pullRequest
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
YAML
복사

테스트가 끝나면 결과에 상관없이 PR 코멘트로 등록하고 슬랙에 알람이 오도록 합니다.

•

새로 작성한 Deploy Workflow

두번째로 배포 부분에선 테스트와 다른 부분만 설명하며 작성하도록 하겠습니다.

name: Deploy WorkFlow

on:
  pull_request:
    types:
      - closed
    branches:
      - 'live'
      - 'dev'
YAML
복사

배포는 Trigger Event의 pull_request 타입이 closed로 merge가 되어 PR이 종료되거나 merge되지 않은채로 PR이 종료될 때 실행됩니다.

jobs:
  Deploy-Job:
    if: github.event.action == 'closed' && github.event.pull_request.merged == true
    runs-on: ubuntu-latest
YAML
복사

merge가 되지 않은 경우엔 배포를 하면 안되기 때문에 if문을 이용해 merge가 되었을 때만 job이 실행되도록 합니다.

# Gradle로 빌드 실행
- name: Run build with Gradle
  working-directory: be
  run: ./gradlew clean build -x test
YAML
복사

테스트와 같이 기본적인 세팅과 secrets 옮기기 등이 끝나면 gradle을 이용해 원하는 모듈을 빌드합니다.

#AWS 인증
- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ap-northeast-2

# deploy 폴더에 배포에 필요한 파일 복사 후 S3 업로드
- name: Zip And Upload to S3
  if: ${{ env.SERVICE != 'all' }}
  run: |
    mkdir be/${{ env.SERVICE }}-deploy
    cp be/module-${{ env.SERVICE }}-api/build/libs/*.jar be/${{ env.SERVICE }}-deploy/
    cp be/appspec.yml be/${{ env.SERVICE }}-deploy/
    cp be/scripts/${{ env.SERVER }}-deploy.sh be/${{ env.SERVICE }}-deploy/deploy.sh
    cp be/agents/*.jar be/${{ env.SERVICE }}-deploy/
    sed -i 's/replace/module-${{ env.SERVICE }}-api-0.0.1-SNAPSHOT.jar/g' be/${{ env.SERVICE }}-deploy/deploy.sh
    zip -r -qq -j be/${{ env.SERVICE }}-deploy.zip be/${{ env.SERVICE }}-deploy
    aws s3 cp --region ap-northeast-2 be/${{ env.SERVICE }}-deploy.zip s3://gocho-deploy/${{ env.SERVICE }}-deploy.zip

# 모든 모듈 deploy 폴더에 배포에 필요한 파일 복사 후 S3 업로드
- name: All Modules Zip And Upload to S3
  if: ${{ env.SERVICE == 'all' }}
  run: |
    mkdir be/user-deploy
    cp be/module-user-api/build/libs/*.jar be/user-deploy/
    cp be/appspec.yml be/user-deploy/
    cp be/scripts/${{ env.SERVER }}-deploy.sh be/user-deploy/deploy.sh
    cp be/agents/*.jar be/user-deploy/
    sed -i 's/replace/module-user-api-0.0.1-SNAPSHOT.jar/g' be/user-deploy/deploy.sh
    zip -r -qq -j be/user-deploy.zip be/user-deploy
    aws s3 cp --region ap-northeast-2 be/user-deploy.zip s3://gocho-deploy/user-deploy.zip
    mkdir be/business-deploy
    cp be/module-business-api/build/libs/*.jar be/business-deploy/
    cp be/appspec.yml be/business-deploy/
    cp be/scripts/${{ env.SERVER }}-deploy.sh be/business-deploy/deploy.sh
    cp be/agents/*.jar be/business-deploy/
    sed -i 's/replace/module-business-api-0.0.1-SNAPSHOT.jar/g' be/business-deploy/deploy.sh
    zip -r -qq -j be/business-deploy.zip be/business-deploy
    aws s3 cp --region ap-northeast-2 be/business-deploy.zip s3://gocho-deploy/business-deploy.zip
    mkdir be/admin-deploy
    cp be/module-admin-api/build/libs/*.jar be/admin-deploy/
    cp be/appspec.yml be/admin-deploy/
    cp be/scripts/${{ env.SERVER }}-deploy.sh be/admin-deploy/deploy.sh
    cp be/agents/*.jar be/admin-deploy/
    sed -i 's/replace/module-admin-api-0.0.1-SNAPSHOT.jar/g' be/admin-deploy/deploy.sh
    zip -r -qq -j be/admin-deploy.zip be/admin-deploy
    aws s3 cp --region ap-northeast-2 be/admin-deploy.zip s3://gocho-deploy/admin-deploy.zip
YAML
복사

빌드가 끝나면 deploy 폴더를 만들어 jar, appspec.yml, deploy.sh, agents 같은 파일을 복사하고 압축합니다.

이 부분이 기존에 3번씩 반복되었던 부분인데 Github Label과 env를 이용해 코드중복을 해소하였습니다.

AWS S3와 CodeDeploy를 사용하기 위해 AWS 인증을 한 후 압축했던 파일을 S3에 업로드합니다.

# Deploy
- name: Deploy
  if: ${{ env.SERVICE != 'all' }}
  env:
    aws-access-key-id: ${{ secrets.AWS_S3_ACCESS_KEY }}
    aws-secret-access-key: ${{ secrets.AWS_S3_SECRET_KEY }}
  run: |
    aws deploy create-deployment \
    --application-name Gocho_BE_Spring_Server_CI_CD \
    --deployment-group-name Gocho_BE_${{ env.SERVICE }}_${{ env.SERVER }}_Deploy \
    --file-exists-behavior OVERWRITE \
    --s3-location bucket=gocho-deploy,bundleType=zip,key=${{ env.SERVICE }}-deploy.zip \
    --region ap-northeast-2

# Deploy All Module
- name: Deploy All Module
  if: ${{ env.SERVICE == 'all' }}
  env:
    aws-access-key-id: ${{ secrets.AWS_S3_ACCESS_KEY }}
    aws-secret-access-key: ${{ secrets.AWS_S3_SECRET_KEY }}
  run: |
    aws deploy create-deployment \
    --application-name Gocho_BE_Spring_Server_CI_CD \
    --deployment-group-name Gocho_BE_user_${{ env.SERVER }}_Deploy \
    --file-exists-behavior OVERWRITE \
    --s3-location bucket=gocho-deploy,bundleType=zip,key=user-deploy.zip \
    --region ap-northeast-2
    aws deploy create-deployment \
    --application-name Gocho_BE_Spring_Server_CI_CD \
    --deployment-group-name Gocho_BE_business_${{ env.SERVER }}_Deploy \
    --file-exists-behavior OVERWRITE \
    --s3-location bucket=gocho-deploy,bundleType=zip,key=business-deploy.zip \
    --region ap-northeast-2
    aws deploy create-deployment \
    --application-name Gocho_BE_Spring_Server_CI_CD \
    --deployment-group-name Gocho_BE_admin_${{ env.SERVER }}_Deploy \
    --file-exists-behavior OVERWRITE \
    --s3-location bucket=gocho-deploy,bundleType=zip,key=admin-deploy.zip \
    --region ap-northeast-2
YAML
복사

그 후 업로드된 S3 파일의 경로와 CodeDeploy의 배포 그룹 등을 지정하여 배포 요청을 보냅니다.

# 배포 결과 슬랙 알람
- name: Slack Alarm
  uses: 8398a7/action-slack@v3
  if: always()
  with:
    status: ${{ job.status }}
    author_name: Github Action Deploy
    fields: repo,message,commit,author,action,eventName,ref,workflow,job,took,pullRequest
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
YAML
복사

배포 요청까지 정상적으로 끝난다면 슬랙으로 job의 결과를 알려줍니다.

workflow를 다 작성한 후 Github Settings에서 branch Protect 설정으로 PR merge를 위해선 Test-Job을 필수로 통과하도록 설정해줍니다.

기존 live서버와 dev서버가 한 개의 ec2 인스턴스에 존재하던 문제점을 해결하기 위해 live서버와 dev서버에 대한 CD를 분리하였습니다.

우선 live서버는 t3.small, dev서버는 t3.micro로 배포하기 위해 시작 템플릿을 분리하였습니다.

나눠진 시작 템플릿에 맞게 AutoScaling 그룹을 분리하였습니다.

위 과정을 통해 나눠진 ec2 인스턴스에 각각 다른 타겟 그룹을 설정해주었습니다.

이 부분은 추후 nginx와 같은 WS를 WAS 앞 단에 둘 예정입니다.

나눠진 타겟 그룹을 로드밸런서가 제어할 수 있도록 80포트와 443포트에 대한 리스너 규칙도 설정해줍니다.

이제 AWS CodeDeploy에 배포 그룹을 나누어 주고 블루/그린 배포를 통한 무중단 배포를 설정해줍니다.

추후 EC2는 ECS로 전환할 예정입니다.

AWS CodeDeploy에도 알람 규칙을 설정해 배포 성공/실패에 따른 알람이 노션으로 오도록 설정해줍니다.

마지막으로 Pull Request를 적극적으로 사용하게 되었으니 PR Template도 설정해줍니다.

## What is this PR?
- Jira Ticket : 
- description :

## Changes
- [add] ...
- [fix] ...

## ScreenShot
none

## Test Cases
- [ ] ...
Markdown
복사

.github 하위에 pull_request_template.md를 작성해줍니다.

표시되는 모습은 위와 같습니다.

테스트

test 브랜치에서 dev 브랜치로의 PR 작성 모습입니다.

이 때 PR의 Label 기능을 이용해 어떤 서비스를 향하는지 지정해줍니다.

PR이 생성됨과 동시에 Test-Job이 정상적으로 작동하는 것을 확인할 수 있습니다.

테스트 성공 시 PR comment와 Slack 알람이 만들어지게됩니다.

PR merge를 하게되면 workflow에서 Deploy-Job이 정상적으로 작동하는 것도 확인할 수 있습니다.

Deploy-Job 역시 실행 결과를 슬랙 알람으로 받아볼 수 있습니다.

빌드된 jar 파일을 AWS S3에 업로드하는 것까지 바뀐 CI 과정을 테스트해보았습니다.

CI 과정을 통해 빌드된 파일로 AWS CodeDeploy에 배포 요청 또한 잘 오는걸 확인할 수 있습니다.

마지막으로 CodeDeploy의 배포 성공 여부가 슬랙으로 도착하는 것을 확인할 수 있습니다.