• Github Action 알아보기 (1) :: 마이구미
    GitHub 2021. 11. 15. 22:25
    반응형
    이 글은 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 를 활용하면서 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개를 통해 원하는 자동화를 할 수 있게 되었다.

    반응형

    댓글

Designed by Tistory.