[Github] 효율적인 개발 프로세스 구축을 위한 필수템, Github Actions

매일 특정 사이트를 크롤링해서 데이터를 추출하거나, 수정사항이 있을 때마다 배포를 하는 등 특정 시간마다 주기적으로 실행시켜야 하는 작업들이 있을 수 있다.
이런 과정을 자동으로 할 수 있게 도와주는 CI/CD 툴들이 이전에도 Jenkins나 전설의 cronjob 등으로 존재했지만,
2018년 github에서 제공하는 Github Actions가 나오면서 판이 뒤바뀌기 시작했다.
이번 글에서는 따로 툴을 구축할 필요도 없이 repository와의 뛰어난 연동성을 지닌 Github Actions에 대해 살펴보고자 한다.
 

CI/CD 란?

CI/CD는 Continuous Integration & Continuous Delivery / Deployment의 약자로, 지속적으로 통합 및 배포하는 과정을 말한다.
테스트하고 배포하는 반복적인 과정을 쉽게 효율적으로 할 수 있는 과정으로, 각 과정의 세부사항은 다음과 같다.

• CI (Continuous Integration)
  : 여러 개발된 코드를 통합하고 빌드한 뒤, 제대로 동작하는지 검증하는 과정
• CD (Continuous Delivery)
  : 애플리케이션 자동 빌드 및 테스트 후, 배포 가능한 상태로 만들어주는 과정
• CD (Continuous Deployment)
  : Continuous Delivery에서 추가로 배포까지 진행하는 과정

이러한 CI/CD를 위한 대표적인 툴로 Jenkins, CircleCI 등이 있다.
다만 이런 툴들은 직접 환경을 세팅해야 하고, github과 관련된 플러그인들이 있긴 하지만
github repository에 변동 사항이 일어나면 바로 작업을 돌리게 하는 등의 설정은 어려웠다.
하지만 github이 직접 제공해주는 Github Actions로는 이런 문제점들이 해결될 수 있다.
툴 자체를 세팅할 필요도 없고, github 내부에 있기 때문에 repository 안에서 일어나는 작업 (github actions에서는 event라고 부른다) 에 대해 모니터링하고 다른 작업을 수행시킬 수 있기 때문이다.
이제 이 좋은 Github Actions를 써먹기 위해 알아야 하는 간단한 개념과 세팅 과정을 알아보고자 한다.
 

Github Actions 관련 주요 개념

대표적인 관련 용어로 Event, Workflow, Job, Action, Runner 가 있다. 각각의 특징은 다음과 같다.

• Events
  : Github Actions를 수행시키기 위한 특정 이벤트를 말한다.
  main 브랜치로 push가 일어났거나, main 브랜치로의 Pull Request가 올라왔거나, 또는 issue가 생성되거나 등
  repository에서 일어날 수 있는 작업 등이 events에 속할 수 있다.
• Workflows
  : event가 일어났을 때 수행할 작업 목록이며, 아래 바로 나오게 될 Job들을 포함하고 있다.
  예를 들어 pull request가 일어나면 단위 테스트, 배포 등을 진행하게 할 수 있는데, 이런 과정들이 묶여 있는 부분이 workflow이다.
• Jobs
  : workflow 내에서 수행할 작업을 말한다.
  위 예시에서 job은 workflow 안에 있는 단위 테스트와 배포 자체를 말한다.
• Actions
  : github에서 직접 제공해주고 있는 기본 작업들로, job 안에서 설정해줄 수 있다.
  - ex1) action check out : 브랜치 체크아웃
  - ex2) action setup node : node 환경 세팅
• Runners
  : Job들이 실제로 실행되는 곳이다.
  vm 머신 또는 docker container라고 볼 수 있으며, github 에서 제공해주는 것 외에 self-hosted로 따로 실행할 환경을 세팅해줄 수도 있다.

 

Github Actions 세팅하기

설정을 원하는 repository에서 Actions 탭에 들어가면 배포, 보안, 자동화, 페이지 관리 등
다양한 상황에 대한 actions를 설정할 수 있는 예시를 제공해준다.
여기에서 원하는 설정에 대해 Configure를 클릭해준다.

 
예를 들어 Simple Workflow를 누르면 아래와 같이 .github/workflows/blank.yml 파일 생성하는 과정이 나온다.
yml 파일 이름을 변경해서 파일 내용 변경 후 저장해주면 된다. 세부 수정사항은 아래와 같이 진행한다.

• name : workflow 이름
• on : workflow 실행시킬 event
• jobs : workflow 내에서 실행할 job 목록으로, jobs 아래에 indentation을 넣고 job 이름을 설정해준다.
  
  • runs-on : job별 수행시킬 환경을 말한다.
    ubuntu-latest 등과 같이 github에서 제공해주는 환경을 이용할 수도 있고, self-hosted로 직접 환경을 구축할 수도 있다.
  • steps : job에서 일어나게 할 작업 목록을 나열해준다.
    각 작업이름을 name으로, 작업마다 수행시킬 명령어를 run에 입력해준다.
    uses를 통해 checkout 등 github에서 제공해주는 action을 직접 이용할 수도 있다.

 

self-hosted 설정하기

앞에서 계속 언급되었던 job을 실행시킬 환경을 직접 세팅하는 방법을 알아보고자 한다.
먼저 repository에서 Settings - Actions - Runners 부분을 클릭해주면 아래와 같은 화면이 나오게 되는데,
여기에서 "New self-hosted runner"를 클릭해준다.

그러면 macOS / Linux / Windows 환경을 선택할 수 있고,
세팅할 환경에 맞게 설정해주고 아래 명령어를 하나씩 복사해서 터미널에 입력해주면 된다.
(명령어는 옆에 화살표를 가져다 대면 복사하기 버튼이 나온다)
참고로 첫번째 mkdir는 꼭 저 경로에서 진행해줄 필요는 없으며, 원하는 경로에 다운로드 및 설치를 진행해줘도 무방하다.

세팅을 하고 run.sh 를 유지한 상태에서 다시 Settings- Actions - Runners를 들어가게 되면,
아래와 같이 새로운 Runner가 추가된 것을 볼 수 있다.

이제 workflow 설정 .yml 파일에서 runs-on 부분을 아래와 같이 [ self-hosted, macOS, X64 ] 로 설정해주면 해당 환경에서 job들을 수행시킬 수 있다.

jobs:
  build:
    runs-on: [ self-hosted, macOS, X64 ]

 
만약 각 job마다 다른 self-hosted runner를 설정하고 싶다면, 아래와 같이 runner 설정에서 labels를 추가해준 뒤

.yml 파일에서는 아래와 같이 label을 하나 더 추가해주면 된다.

jobs:
  build:
    runs-on: [ self-hosted, macOS, X64, unit-test ]

 

참고자료

https://github.com/features/actions

Features • GitHub Actions

https://www.youtube.com/watch?v=iLqGzEkusIw