오늘도 고도화할게 뭐가 있을까하고 두리번 거리던 프론트엔드 개발자 A씨. 그순간 그녀의 눈에 띈건 비슷한 내용으로 여러개 작성되어 있던 Github action workflow 파일들 ! 중복을 최소화하고 재사용성을 높힐 수 있는 방법이 없을까 하고 구글링을 하던 중 'Reusing workflows'라는 글을 보게 되었고 바로 실행에 옮겼다.
본인은 Github action을 배포 자동화를 위해 사용하고 있는데, 브랜치 전략에 따라 develop, stage, product 브랜치에 푸시나 PR이 머지되면 자동으로 배포되게 workflow 파일을 구성해 놨다.
배포의 구성은 모든 workflow파일이 동일한데 다른 점은 env파일, AWS버킷 URL 그리고 AWS distribution ID 총 세개 뿐이다. 이 다른 세개를 위해 70줄이 되는 비슷한 파일이 3개가 존재하고 있던것이다.
리액트에서 공통컴포넌트를 만들어 변경되야하는 부분만 props로 받아 사용하듯이 Reusable workflow를 구성하게 된다면 변경되는 부분만 제외하고 나머지는 재사용 할 수 있을것이라는 기대효과를 위해 작업을 시작하였다.
Reusable workflow 구성을 위해 workflow가 최소 2개가 필요한데 하나는 called workflow(공통 workflow) 다른 하나는 caller workflow(상황에 따라 달라지는 workflow)이다.
우선 공통이 되는 Reusable workflow를 작성해보자.
name: Reusable Deploy Workflow
on:
workflow_call:
secrets:
AWS_S3_BUCKET_URL:
required: true
inputs:
env:
required: true
type: string
jobs:
build:
runs-on: ubuntu-20.04
steps:
- run: cp ${{ inputs.env }} .env
... 생략
- name: Copy the files from build folder to the S3 bucket
run: aws s3 sync . ${{ secrets.AWS_S3_BUCKET_URL }} --cache-control max-age=31536000
working-directory: ./dist/
현재 workflow_call안에는 설명을 위해 secrets하나 inputs하나로 구성되어있지만 각자 workflow의 구성에 따라 변하는 요소들은 다 저기에 선언해 놓으면 된다. 이 부분에 대해서는 caller workflow에서 연관지어 설명하도록 하겠다.
공통 컴포넌트를 구성했으니 이제 props를 넘겨줄 일만 남았다.
dev브랜치에 푸시되면 배포하는 workflow를 새로 구성해보자.
name: Dev deploy
on:
push:
branches: dev
jobs:
deploy-dev:
uses: [owner name]/[repo name]/.github/workflows/deploy-project.yml@dev
with:
env: env/dev.env
secrets:
PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
AWS_S3_BUCKET_URL: ${{ secrets.AWS_S3_BUCKET_URL }}
... 생략
우선 파일에 작성되어 있는 코드 수가 획기적으로 줄었다.
Called workflow에만 기존 workflow와 비슷한 70줄 정도 작성이 되어 있고 caller workflow 파일 하나에는 18줄 밖에 작성되어 있지 않다.
파일 3개 * 70줄 = 210줄(기존) -> 70줄 + 18 x 3 = 124줄(현재)
210줄에서 124줄, 즉 41%정도 반복되는 코드를 줄였다.
또한 앞으로 다른 개발자가 자동 배포를 구축해야할때도 같은 코드를 작성하지 않고 변화가 필요한 부분만 called workflow에 넘겨주게 된다면 아주 빠르게 배포환경을 구축할 수 있을것이다.