[CI/CD] CI/CD와 Github Action 살펴보기

안녕하세요

'CI/CD와 Github Action 살펴보기' 라는 주제로 진행한 Speaker Session을 정리한 글입니다!

⬇️ 아래는 발표 자료 파일 입니다 ⬇️

GDSC-GithubAction.pdf

8.04MB

 

1. CI/CD란?

CI/CD란, 작업한 소스코드를 빌드하고 저장소에 전달 후 배포까지 하는 모든 과정을 자동화하여 어플리케이션을 보다 짧은 단위로 고객에게 제공하는 방법이다.

CI (Continuous Integration)

- 지속적 통합

- 개발을 진행하면서도 코드의 품질을 관리할 수 있도록 한다.

- 여러 명이 하나의 코드에 대해 수정을 진행할 때에도 지속적으로 통합하면서 관리할 수 있다.

- CI의 목표: 버그를 신속하게 찾아 해결하여 소프트웨어의 품질을 높이고, 새로운 업데이트의 검증 및 릴리즈 시간을 단축시킨다.

CD (Continuous Delivery 혹은 Continuous Deployment)

- 지속적 제공 혹은 지속적 배표

- 지속적 제공: CI를 거치며 소스코드 빌드, 테스트까지 성공적으로 진행되었다면, 빌드와 테스트를 거쳐 github 등의 저장소에 업로드한다.

- 지속적 배포: 성공적으로 병합된 내용을 저장소 뿐 아니라, 사용자가 사용할 수 있는 환경에 배포, 릴리즈 한다.

- CD의 목표: 사용자가 최대한 빠른 시간 내에 최신 버전의 소프트웨어를 제공받을 수 있도록 하고, 이를 통해 배포까지의 노력을 최소한으로 단축시킨다.

CI/CD를 적용하기 전과 후의 차이

CI/CD를 적용하기 전

개발자가 각자의 브랜치에서 개발한 후, 코드를 합친다. 이때 오류가 나면 어느 부분의 코드에서 나는지 정확히 알 수 없다. 따라서 개발자가 직접 디버깅을 거치며 코드를 하나하나 확인하는 작업을 고쳐야 한다.

CI/CD를 적용하고 난 후

개발자가 각자의 브랜치에서 개발한 후, 푸시하는 과정에서 CI가 빌드, 테스트 등을 실행하고 결과를 전송한다. 이때 결과에 오류가 있다면 개발자는 해당 부분을 고친 후 다시 코드를 합친다.

 

-> 결국 CI/CD를 적용하고 나면 개발자가 불필요하게 시간을 낭비하지 않도록 해주고, 코드를 올리는 것 만으로 자동으로 코드 테스트, 빌드, 배포까지 자동화할 수 있다. 따라서 개발자는 개발에 더 많은 시간을 투자할 수 있고, 코드의 품질이 올라간다.

CI/CD 환경 만들기

Jenkins, Travis, Circle, Github Action 등을 이용하면 된다.

 

2. Github Action 이란?

Github에서 공식적으로 제공하는 CI/CD툴로, 소프트웨어 워크플로우를 자동화 할 수 있도록 도와준다.

- Github 내의 어떤 이벤트가 발생하면(ex. pull, push, merge등) 해당 이벤트에 대해 정해진 동작을 실행한다.

- Public Repository의 경우에만 무료로 제공한다.

- 특정 이벤트에 대한 동작을 정의해놓으면, 해당 이벤트가 발생할 때마가 자동으로 테스트하고 프로젝트에 문제가 있는지 확인한다.

 

3. Github Action의 구성 요소

Github Action은 Workflows(워크플로우), Events(이벤트), Job(작업), Runners(러너), Step(스텝), Action(액션)으로 구성되어 있다.

1) Workflows (워크플로우)

- 저장소에 추가하는 자동화된 프로세스로, 하나 이상의 job으로 이루어져 있다.

- 각 Repository의 .github/workflows 폴더 아래에 YAML file(.yml)로 저장되며, 이벤트에 의해 예약되거나 트리거될 수 있는 자동화된 절차들이 담겨있다.

 

2) Events (이벤트)

- 워크 플로우를 실행하는 특정 활동이나 규칙

- ex) 누군가가 커밋을 푸시했을 때, PR을 열었을 때 등

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

Events that trigger workflows - GitHub Docs

 

3) Job 

- Workflow의 기본단위

- step으로 이뤄져 있고, 워크플로우는 여러 job들을 병렬적으로 실행한다. (순차적으로 실행되도록 할 수도 있다.)

 

4) Runners

- 워크플로우가 실행될 Github Action Runner Application이 설치된 하나의 서버 (테스트를 실행할 컴퓨터)

- Github Action에서는 Ubuntu Linux, Microsoft Windows, MacOS 러너를 제공한다.

- 워크플로우의 각 작업은 새로운 가상환경인 러너에서 실행된다.

 

5) Step

- job에서 커맨드를 실행하는 독립적인 단위

- 한 Job의 각 Step들은 동일한 Runner에서 실행된다.

- Step에서 명령을 내리거나 Action을 실행할 수도 있다.

 

6) Action

- 워크플로우의 가장 작은 요소

- 사용자가 직접 만들어서 사용할 수도 있고, 마켓에 등록된 이미 만들어진 것을 가져와 사용할 수도 있다.

 

 

4. Github Action 시작하기

 

1. Github Action을 사용하려는 Repository에 Workflow를 추가합니다.

워크플로우 파일은 .github/workflows폴더 아래에 .yml 파일을 추가하여 등록합니다. 직접 yml 파일을 추가할 수도 있지만, Github Action 탭에 가서 원하는 추천 템플릿을 선택해도 됩니다.

 

2. set up a workflow yourself를 클릭해 새로운 yml 파일을 생성해보도록 하겠습니다.

- name: Github Repository의 Action 탭에 보이는 워크플로우의 이름

- on: 워크플로우의 트리거를 정의한 부분

위의 경우는 main branch에 푸시할 때나 Pull Request를 날릴 때 이벤트가 발생한다는 것을 정의해준 것이다.

 

- jobs: 이벤트가 트리거되면 실행되는 부분을 정의한다.

- runs-on: 가상 머신을 어느 플랫폼에서 실행시킬지 결정 (Ubuntu, Window, MacOS가능)

- Steps: 이벤트가 트리거되면 실제로 실행된느 부분

- uses: 이미 만들어진 액션을 사용할 때 

- run: 실행할 명령어 (많은 경우 | 를 입력하고 그 아래에 작성한다.)

 

3. 이후 커밋하면 작성해준 명령어가 실행되면서 테스트되는 것을 볼 수 있습니다.