Github Action

CI / CD 란?

CI/CD는 Continuous Integration(지속적 통합) / Continuous Delivery(지속적 전달) 의 줄임말이다.

 

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "인테그레이션 헬(integration hell)")을 해결하기 위한 솔루션입니다.

 

새로 개발한 기능, 버그 수정점 등을 실제 배포 중인 서비스에 통합하기 위해서는 여러 과정이 필요하다. 소스코드를 테스트하고, 빌드하고, 컨테이너 화하여 통합적인 저장소에 전달 후 서비스 무 중단 배포 등의 과정이 그것이다. 이 모든 과정을 통상적으로 CI/CD라고 부른다.

 

특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공합니다. 이러한 구축 사례를 일반적으로 "CI/CD 파이프라인"이라 부른다.

 

더 자세히 말하면, CI는 테스트, 빌드, Dockerizing, 저장소에 전달 까지 프로덕션 환경으로 서비스를 배포할 수 있도록 준비하는 프로세스를 말하고, CD는 저장소로 전달된 프로덕션 서비스를 실제 사용자들에게 배포하는 프로세스를 의미한다.

CircleCI, TravisCI, Jenkins, Atlassian - Bamboo, 등 여러 CI/CD를 위한 툴이 많다.

 

 

 

Github Actions이란?

github에서 공식적으로 제공하는 CI / CD 툴(개발 워크 플로우 자동화 툴)이라고 보면 된다.
기존에 이미 Github과 서드파티 서비스들을 연동하여 자동화 해왔다. (TravisCI, CircleCI, Jenkins, CodeCov 등) 연동을 통해서 진행했던 많은 CI 작업들을 이제 Github(뒤에 MS를 업은)이 공식적인 기능으로 지원하게 되어, 개발 환경이 분산되지 않고 일원화된 개발 환경(GIthub)을 통해 많은 모든 과정을 통합적으로 관리할 수 있게 되었다.

https://pages.github.sec.samsung.net/CODE-Actions/actions-guide/docs/quickstart/

 

Github Actions로 할 수 있는 일
npm에 패키지를 배포, Docker Hub에 이미지를 배포, AWS 에 서비스를 배포, GCP 에 서비스를 배포 하는 작업 등을 Github에서 바로 할 수 있다. 기존의 익숙한 Git/GIthub 기능인 Pull Request, Push 등을 통해서 말이다.

또한, 브랜치 별로 어떤 Action을 실행할 지 설정할 수 있어 각 개발 팀에 최적화 된 workflow를 만들어 낼 수 있다.

 

 

Github Actions의 개념 
Workflow : 자동화된 전체 프로세스를 나타낸 순서도. Github에게 YAML파일로 정의한 자동화 동작을 전달하면, Github Actions는 해당 파일을 기반으로 그대로 실행시킨다.

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on

name : workflow의 이름으로, repo의 actions page에 표기됨

on : 자동으로 workflow를 trigger하기 위해서는 on을 사용하여 어떤 event가 workflow를 실행시킬지를 명시

        생성할 수 있는 event 들에 대한 참고

branch: 특정 event가 발생한 branch 지정 가능 -ignore이나 ! 키워드로 exclude표시 가능 (tag도 마찬가지)

paths: push/pull_request 이벤트를 사용할 경우, 어떤 파일의 경로가 변경되는지에 따라 workflow를 실행할 수 있음

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

Job : 그룹의 역할로, 단일 가상 환경을 제공한다.

workflow내의 같은 runner에서 실행되는 step의 집합. 각 step은 실행될 shell script이거나 action이며 순서대로 실행되고 서로 영향을 준다. 같은 runner에서 실행되므로 data를 공유할 수 있다. 예를 들면 빌드 후에 test시에는 빌드된 환경이다.

job끼리는 기본적으로 dependency가 없고 서로 병렬로 실행된다, 하지만 dependency를 configure할 수 있다. (A job이 끝나기를 B job에서 기다릴 수 있음) -> job id를 통해 dependencies설정 가능

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

env를 사용하여 해당 job 컴퓨팅 자원에 설정할 환경 변수를 key=value형태로 명시 가능

strategy를 사용하여 jobs가 여러 환경에서의 테스트/배포 등을 위해 build matrix를 설정할 수 있음

https://docs.github.com/en/actions/using-jobs/using-jobs-in-a-workflow

Step : Job안에서 순차적으로 실행되는 프로세스 단위로, 파일 시스템을 통해 서로 정보를 공유, 교환할 수 있다. step에서 명령을 내리거나, action을 실행할 수 있다. task들의 집합으로 커맨드를 날리거나 action을 실행할 수 있다.

Action : 타인들 또는 작성자에 의해서 미리 정의된 호출 매커니즘을 불러와 사용할 수 있다. 사용자가 직접 커스터마이징하거나, 어느 나/그룹/개발팀/제품/회사 등에서 정의한 action을 불러와 사용할 수 있다. Github Marketplace에서 공유되고, marketplace에 공유된 action은 yaml 파일에서 곧바로 사용할 수 있다.

복잡하지만 반복적으로 자주 사용되는 task들을 수행하는 custom application for github actions platform이라 할 수 있다.

action을 사용하면 반복적으로 사용되는 많은 양의 workflow코드를 줄일 수 있다.

Event : workflow 실행 기준으로, cron과 같이 시간에 따라 작업을 실행하게 할 수도, git push / pull-request 등의 GIthub Repository 이벤트를 기준으로 실행하게 할 수도 있다.