Github Action 알아보기 (1) :: 마이구미

이 글은 Github Action 을 활용한 예제를 다뤄본다.
예제는 Github Action 을 활용한 CI/CD 를 구축해본다.
예제 코드 - https://github.com/hotehrud/github-action-test
Github action - https://github.com/features/actions

 

Github Action 은 Github 에서 공식적으로 지원하는 소프트웨어 개발의 워크플로우를 자동화해주는 도구이다.

기존에는 CI/CD 를 위해서 Jenkins, Amplify, CircleCi, TravisCi 등을 사용하고 있었다.

CI/CD 를 위한 별도 서버가 필요하거나 도구를 위한 비용을 지불할 수도 있다.

비용이 무료이거나 별도 서버 구축까지 필요없더라도 대부분 저장소와는 별개의 서비스를 사용해야했다.

하지만 Github Action 은 Github 자체에서 제공해주기 때문에 이미 저장소로 Github 을 사용하고 있다면 더할나위없이 좋다.

 

---

 

Github Action 으로 간단한 CI/CD 를 구축해본다.

 

우선 Git 워크플로우 전략은 Git-flow 을 따른다.

Git-flow 전략은 딱 정해진 것이 없고 개인마다 회사마다 조금은 다를 수 있지만 큰 그림은 동일할 것이다.

예제를 위한 배포 시점에서의 브랜치를 확인해보자.

 

1. dev 브랜치는 다음 릴리즈를 위한 기능들이 합쳐진 상태이다.
2. dev 브랜치를 기준으로 release 브랜치를 생성하고 QA 를 거쳐 버그 수정이나 추가 코드들이 추가되었다.
3. release 브랜치를 기준으로 배포가 진행된다.
4. 배포가 완료되면 release => master => dev 순으로 합쳐진다.

 

위 흐름을 기반으로 배포 완료 후 필요한 워크플로우는 생각해보자.

4번에 해당한다.

release -> master -> dev 순으로 코드 병합이 필요하다.

그리고 추가로 배포 버전에 대한 태그를 추가하는 것이 있다.

여기서 우리가 필요한 자동화는 배포 후 브랜치들의 머지와 버전을 위한 태깅이다.

 

배포의 경우에는 AWS S3 에 배포한다고 가정하면 가장 간단한 방식은 무엇인가?

로컬에서 aws cli 를 통해 배포하거나 이를 기반으로 배포 스크립트를 작성하여 스크립트를 실행할 것이다.

여기서 우리가 필요한 자동화는 이러한 배포 방식을 개선하는 것이다.

---

 

위 2가지 자동화를 Github Action 이 대신해줄 것이다.

2가지 워크플로우는 다음과 같다.

 

• s3 배포
• 배포 후 브랜치 머지(Merge) 그리고 버전 태깅(Tagging)

 

push, pull_request 이벤트 발생을 탐지해서 그 시점에 자동으로 배포가 이루어지는 예제들이 많다.

대부분의 경우에서 수동보다 자동이 당연히 좋지만, 개인적으로 이 부분은 수동을 선호한다.

여기서는 수동이라는 것은 배포 버튼이 존재하고 사용자 클릭을 통해 배포가 시작되는 것을 의미한다.

 

결과적으로 2가지 워크플로우가 버튼으로 만들어진다면 다음과 같다.

 

 

Run workflow 를 버튼을 통해 각각 워크플로우를 실행하는 것이다.

위 그림은 2개의 워크플로우 파일을 생성하면 위와 같이 노출될 것이다.

워크플로우는 저장소에서 Actions 탭에서 생성하거나 루트 디렉토리 경로에서 .github/workflows/*.yml 형태로 생성할 수 있다.

 

먼저 배포를 위한 워크플로우를 만들어보자.

일반적으로 배포의 흐름은 다음과 같다.

 

1. 모듈 설치(npm install or yarn)
2. 빌드
3. 빌드 파일을 S3 업로드

 

워크플로우도 위와 같은 흐름으로 YML 문법으로 작성된다.

 

name: 'S3 배포'

on:
  workflow_dispatch:

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      # 코드 가져옴
      - name: Checkout code
        uses: actions/checkout@v2
        with:
         token: ${{ secrets.GITHUB_TOKEN }}
        
      # Node.js 14.x 버전 사용
      - name: Setup Node.js environment
        uses: actions/setup-node@v2.4.1
        with:
          node-version: '14.x'

      # 모듈 설치
      - name: Install Dependencies
        run: yarn

      # 빌드
      - name: Build yarn
        run: yarn build

      # S3 업로드
      - name: Deploy s3
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --follow-symlinks --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: ${{ secrets.AWS_REGION }}
          SOURCE_DIR: "build"

 

 

on: workflow_dispatch 의미가 버튼을 통해 워크플로우를 수동으로 실행하겠다는 것이다.

각각의 job 을 순서대로(steps) 실행하게 되는데 각 job 에는 uses 가 존재한다.

uses 는 액션이라고 불리고 플러그인 또는 모듈이라고 보면 이해하기 쉽다.

이미 만들어져있는 액션을 활용해서 쉽게 워크플로우를 작성할 수 있다.

 

실제로 Github 페이지 Actions 탭에서 워크플로우를 생성하면 검색 필터링을 통해 원하는 액션을 쉽게 찾을 수 있다.

작성된 step 은 다음과 같다. 

 

1. Github 에 저장된 코드를 체크아웃 (워크플로우 실행에 선택한 브랜치 기준)
2. Node.js 환경 셋팅
3. 빌드
4. S3 업로드

 

그리고 secrets.GITHUB_TOKEN, secrets.AWS_S3_BUCKET 등을 볼 수 있다.

secrets.GITHUB_TOKEN 은 자체적으로 제공해주기 때문에 그대로 사용하면 된다.

AWS_S3_BUCKET, AWS_ACCESS_KEY_ID 와 같은 것들은 별도로 설정한 것이다.

 

 

Settings 탭에서 Secrets 메뉴에서 설정할 수 있다.

설정한 값을 위 코드처럼 그대로 사용하면 된다.

 

사용하는 플러그인들은 각 저장소에 찾아가서 README.md 를 참고하면 된다.

https://github.com/actions/checkout

https://github.com/actions/setup-node

https://github.com/jakejarvis/s3-sync-action

 

 

이번에는 Merge와 Tagging를 위한 워크플로우를 만들어보자.

 

워크플로우의 순서는 다음과 같다.

 

1. release 에서 master 머지
2. master 에서 dev 머지
3. 버전 태그 생성

 

name: Sync branch

on:  
  workflow_dispatch:

jobs:
  sync_job:
    runs-on: ubuntu-latest
    steps:
      - name: Sync ${{ github.ref }} to master
        uses: devmasx/merge-branch@master
        with:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
          type: now
          from_branch: ${{ github.ref }}
          target_branch: master  
          
      - name: Sync dev with master
        uses: devmasx/merge-branch@master
        with:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
          type: now
          from_branch: master
          target_branch: dev
      
      - name: Bump version and push tag
        id: tag_version
        uses: mathieudutour/github-tag-action@v5.6
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          release_branches: release

      - name: Create a GitHub release
        uses: ncipollo/release-action@v1
        with:
          tag: ${{ steps.tag_version.outputs.new_tag }}
          name: Release ${{ steps.tag_version.outputs.new_tag }}
          body: ${{ steps.tag_version.outputs.changelog }}

 

여기서도 누군가 잘 만들어주신 플러그인을 사용한 모습을 볼 수 있다.

 

• merge-branch
• checkout
• github-tag-action
• release-action

 

merge-branch 를 활용하면서 from_branch, target_branch 에 원하는 값을 기입했다.

release -> master 를 머지한 후 master -> dev 를 머지한 모습을 볼 수 있다.

github.ref 는 현재 선택된 브랜치라고 보면 된다.

 

그리고 github-tag-action 을 통해 태깅을 하는 모습이다.
이 액션에서 제공해주는 기능은 커밋을 분석해서 자동으로 버전을 올려준다.

release_branches 의 기본값은 master, main 이지만 여기서는 release 를 명시했다.

이유는 releaes/20211115 와 같은 형태에서 워크플로우를 실행하면 안 맞는 부분이 있어서 오류가 난다.

 

마지막으로 release-action 을 통해 릴리즈 노트를 생성해준다.

steps.tag_version.outputs.new_tag 를 접근할 수 있는 이유는 위에서 id 를 tag_version 으로 명시주었기 때문이다.

 

2개의 워크플로우를 만들어보았다.

다음과 같은 순서로 워크플로우를 사용할 수 있다.

 

1. release 브랜치에 배포할 버전을 푸시한다.
2. 배포 워크플로우를 통해 release 브랜치를 선택하고 실행한다.
3. 배포가 완료되면 머지 && 태깅 워크플로우를 통해 release 브랜치를 선택하고 실행한다.

 

이렇게 버튼 2개를 통해 원하는 자동화를 할 수 있게 되었다.