과거의 내가 미래의 나에게
자유롭게 CI/CD에 대해 공부해볼래(3) 본문
저번 글에서 우리 프로젝트에서 쓰일 도구로 git, git action 그리고 docker로 선정하였다. 오늘부터는 해당 도구에 대해서 알아볼 것인데, 오늘은 git action에 대해서 알아보도록 하겠다.
git action 이란?
git action은 github에서 제공하는 서비스로 빌드, 테스트 및 배포 파이프라인을 자동화 할 수 있는 CI/CD 플랫폼이다.
git action을 사용함으로써 한 레포지토리에서 PR이나 push 등 특정 이벤트가 발생하면 코드에 대한 테스트 같이 특정 작업을 자동으로 실행하게 할 수 있고, 데이터 수집같은 특정 작업을 주기적으로 반복해서 실행시킬 수 있는 등 다양한 CI 과정을 만들어 낼 수 있다.
github으로부터 출발한 서비스인만큼 github의 기능과 유연하게 연결시킬 수 있는데, 코드와 CI/CD 설정이 같은 저장소에 있으므로 통합적으로 관리하기 유용하고, 이슈나 pr같은 github의 기능으로 더욱 원활한 CI 구성을 마련할 수도 있다.
또한 github marketplace을 통해 사람들이 미리 작성한 작업을 쉽게 쓸 수 있어 CI 구축을 한층 더 쉽게 구성할 수 있게 한다.
git aciton 구성요소
git action이 실행되는 과정은 아래와 같다.
특정 레포지토리에 pull이나 pr과 같은 event가 발생하면 yaml 파일로 작성된 workflow가 실행된다, 이 workflow는 한 개 이상의 jobs로 구성되고, 각 jobs는 runner라고 부르는 가상머신에서 실행되며, jobs 내부에는 하나 이상의 steps로 구성되어있는데 이 steps을 통해 shell 명령을 실행하거나 각종 실제 작업을 실행할 수 있다.
개략적인 git action의 구성은 위와 같은 식으로 흘러가게 되고, 이제 구문을 보면서 좀 더 자세히 살펴보겠다.
참고로 여기 github docs에서 구문에 대한 설명이 자세히 되어있으니 참고하여도 좋다.
name: Build and Test
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '14'
- name: Install dependencies
run: npm install
- name: Build
run: npm run build
- name: Test
run: npm test
1. workflows
workflow는 git action의 기본 구성으로 여러 수행 목록들을 묶어놓은 작업 그룹이라 생각하면 된다. 한 workflow에 실행할 작업 목록(jobs에 해당하는 부분)을 쭉 적어놓고 이를 언제 실행시킬지만 정하면(on에 해당하는 부분. event라고도 한다.) git action의 사용 준비는 끝났다고 생각하면 된다.
구성요소는 다음과 같다.
■ name
workflow의 이름이다. 생략하면 workflow 파일의 이름을 따라가게 된다.
■ on
workflow가 언제 실행되는지에 대한 정보를 적는 곳이다. push, commit, pull, PR 등 github 레포지토리에서 일어날 수 있는 이벤트들을 한 개 이상으로 적는다. 각 이벤트들을 이벤트들만의 개별 속성이 있다. 예를 들어 push할 때 workflow가 실행되게 하고 싶은데, 모든 branch에 대해 발동하지 않고 특정 branch에서 push 시 발생하고 싶을 때, "branch"란 속성을 이용하여 지정할 수 있다는 것이다.
git action에서 사용할 수 있는 이벤트들과 또 그 속성은 github docs에 적혀있으니 필요할 때 찾아보거나 시간이 난다면 슥 훝어보는 것도 도움될 것 같다.
■ jobs
이 부분은 아래에서 살펴보겠다.
하나의 레포지토리에 여러 workflow가 존재할 수도 있다. 예를 들어, 하나의 workflow에서는 pull 이벤트 발생 시 빌드 후 테스트하는 과정을 진행하는 것을 만들고 또 다른 workflow에서는 push 시 자동으로 pr 생성하는 것을 만들 수 있다는 것이다.
2. jobs
jobs는 workflow 내에서 실제로 실행되는 작업들을 그룹으로 묶은 것으로, 사실상 workflow의 메인 부분이라 할 수 있다.
가장 먼저 jobs의 이름을 적고(위 예시에서는 bulid라 적혀있다), 그 다음 "runs-on"에서는 해당 jobs를 기동시킬 가상 머신을 적는다. 그리고 jobs가 어떤 작업을 어떤 순서로 진행하는지에 대해 "steps"에다가 서술하면 하나의 jobs의 구성이 완료된다.
■ runners
jobs가 실행할 가상 머신을 나타낸다. 이는 github에서 제공하는 runner를 사용할 수도 있고 본인이 직접 준비한 runner를 사용할 수도 있다.
■ steps
jobs의 구성요소로 jobs 내에서 순차적으로 실행된다. workflow 내에서의 가장 작은 실행 단위이다.
단순한 커맨드로 이루어질 수도 있고 스크립트일 수도 있으며 action이라는 좀 더 복잡한 명령을 적을 수도 있다. action에 대해서는 아래에서 더 상세히 살펴보겠다.
한 workflow 안에 여러 jobs를 넣을 수 있고, 각 jobs는 기본적으로 병렬적으로 실행되며 "needs" 키워드를 통해 순차적으로 실행할 수 있게끔 조절할 수도 있다.
3. actions
하나의 작업을 모듈화 시킨 것이라 할 수 있다. CI를 구축하다보면 분명 자주 쓰이고 반복적인 부분이 나타날텐데 이것을 action으로 만들어놓으면, 후에 동일한 작업을 해야할 때 일일이 코드를 다시 다 적을 필요가 없고 적어놓은 action을 가져와서 붙이기만 하면 되는 것이다.
이러한 action은 본인 뿐만 아니라 다른 사용자들도 사용할 수 있도록 공유가 가능하여 더 많은 사람들이 편리하고 기발하게 CI 생태계를 구축하고 발전하는데 도움을 주고 있다. 타인이 만든 action을 보고 싶다면 github marketplace에 들어가보자.
마무리
git aciton을 통해서 push 시 자동으로 pr 생성, 코드 통합 시 테스트, 도커 이미지 빌드, 빌드 성공 시 프로덕션 환경으로 자동 배포, 사용하지 않을 브랜치 리소스 정리, 외부 서비스와의 통합 등 아주 다양한 일을 자동으로 해낼 수 있다.
공부를 하다보니 git action에 대한 모든 것을 다 파악하기보다는 CI를 구축하는데 필요한 부분이 무엇인지 먼저 고민한다음 그것이 가능한지를 서치하여 구축해나가야겠다는 생각이 들었다.
어떤 방법이 더 이로운 방법인지를 빠르고 명확하게 알기 위해서는 다양한 환경을 구축해보고 운영해보는 것이 필수인 것 같다. 좋은 도구들이 많이 나와서 많은 개발자가 devOps를 쉽게 할 수 있게 됐지만 훌륭한 devOps를 구축하는 개발자는 드물겠구나 하는 생각이 들기도 하였다.
이제 git action의 사용법에 대해 어느정도 알았으니 내가 필요한 CI가 어떤 것인지 고려해보고 git aciton을 활용하여 작업할 일만 남았다.
참고 문서
- GitHub Actions의 소개와 핵심 개념 - https://somaz.tistory.com/213
- Github Action이란? - https://www.daleseo.com/github-actions-basics/