대부분의 프로젝트에서는 CI/CD를 사용하고있다. CI/CD는 대체 뭐고 왜 이를 제공해주는 툴들을 많이들 사용하는 걸까?(Jenkins라던지 Github Action이라든지)
궁금증을 해결하기 위해서 CI/CD란 무엇을 뜻하는 것이고 CI툴 중에서 Github Action에 대해서 알아보자.
CI/CD란 무엇이고 왜 필요할까?
CI/CD의 목적은 무엇인가?
반복적인 일(빌드, 테스트, 배포 작업 등)들을 처리하고 문제가 있을 때 경고를 해주는 등 자동화된 파이프라인을 통해서 코드 변경과 배포 단계를 원활하게 진행할 수 있다.
즉, 자동화를 통해 시간 절약 및 사람이 직접적으로 처리할 때 실수할 수 있는 부분들을 관리할 수 있다.
CI(Continuous Integration)는 지속적인 통합을 뜻한다.
- 추가,변경(push나 pull request)된 코드를 빌드하고 테스트 하는 프로세스를 자동화하는 것
- 위와 같은 프로세스를 거친후에 병합(통합) 즉, 코드를 merge해주는 것
- 다수의 인원이 함께 개발할때 충돌과 같은 일들을 미연에 방지 가능하며 Lint(코드 규칙)를 잘 지켰는지, 제대로 동작하는지 등 확인가능
CD(Continuous Delivery, Deployment)는 지속적인 제공 및 배포를 뜻한다.
- Delivery과정은 CI 과정을 거친후에 병합하여 실행테스트를 할 수 있도록 하는 것
- Deployment는 뜻 그대로 배포 과정을 자동으로 처리 해주는 것이다.
Github Action이란
Github Action이란?
Github 저장소를 기반으로 Workflow를 자동화 할 수 있는 도구. Github가 제공하는 완전관리형 CI/CD 툴이다.
Github Action 특징
특징
- 컨테이너(도커) 기반으로 동작함
- 개발자는 Workflow를 작성하여 다양한 이벤트를 기반으로 실행시킬 수 있다.
- Workflow는 Runners(기본 Azure, self-hosted 가능)라 불리는 인스턴스에서 Linux, macOS, Windows 환경에서 실행됨 - 원하는 OS 지정할수 있음. 한 번에 여러 OS에서 테스트 가능
- Gihub 마켓 플레이스에서 여러 사람이 공유한 Workflow를 찾아서 사용할 수도 있고 직접 만들어서 공유할 수도 있음
- YAML로 작성
장점
- 다른 CI/CD툴(Jenkins)들 처럼 서버설치가 필요하지 않음. 제공해주는 클라우드(Azure)가 있음
- 비동기적 병렬실행이 가능한 CI/CD
- Github 마켓 플레이스를 이용하여 Workflow를 가져다 쓰거나 공유할 수 있음.
- Github에서 제공하는 완전 관리형 서비스이므로 설정이 매우 쉽움.
단점
- 캐싱이 필요한 경우에는 자체 캐싱 로직을 작성해야함
- 서버에 장애가 일어나거나 리소스를 초과할 경우 개발자가 직접 문제를 해결해야한다.
Github Action 핵심 개념
Workflows
자동화된 프로세스가 정의되어 있는 하나의 파일이다.
Github Action에서 가장 최상위 개념으로
- YAML 파일로 작성됨
- 해당 파일을 트리거(실행)할 규칙, 실행할 동작이 작성되어 있음.
Runners
Workflow가 실행될 인스턴스로 클라우드에서 동작한다.
다른 CI툴처럼 서버가 필요없는 이유로 기본적으로 Github Action이 인스턴스를 제공하기 때문이다.
기본적으로 MicroSoft의 Azure에서 동작하며 실행할 인스턴스(self-hosted-runner)를 등록할 수 있다.
Events
Workflow를 실행할 특정한 활동(push 등)이나 규칙이다.
당연하게도 Workflow 파일 내에 정의해 놓는다.
예를 들어, ‘git에 push 했을때’ 혹은 더 구체적으로 ‘어떤 branch에 push나 pull request를 했을때’ 등의 규칙을 정의할 수 있다.
Jobs
Workflow내에서 실행될 명령.
Event로 Workflow가 실행되면 Job에 작성된 명령들이 실행된다.
- Workflow내에서 여러개의 Job을 작성할 수 있다.
- 위에서 설명한 Runner에서 실행된다.
- 기본적으로 Job들은 병렬로 실행되지만 서로 의존관계를 가질 수도 있고 직렬로 실행할 수 있다.
- Job은 자신의 환경설정과 Steps를 가지고 있다.
Steps
Job내에 steps명령어 안에 존재한며 여러개의 step들로 구성되어 있다.
- 각 step들은 script, 명령어 또는 action을 실행할 수 있다.
- 각 step들은 데이터를 공유할 수 있다
Actions
재사용되는 명령어들의 집합으로 이루어진 작업이다. 컴포넌트라고 볼 수 있다.
- 직접 작성해도 되고 Markey에 등록되어 있는 Action을 가져와 사용할 수도 있다.
Github Action 명령어 사용법
각 레포지토리의 최상단에 .github/workflows 디렉터리를 만들고 그 내부에 이름.yml 파일을 만들면 workflow 파일 생성 완료. 각 workflow 파일 내부에는
최상단에 name 작성 : workflow의 이름을 설정해주는 것
name: workflow testworkflow를 실행시킬 Event정의 : 아래는 master branch에 push이벤트가 일어날 때 라는 뜻
on:
push:
branches:
- masterEvent에 부합했을때 실행 시킨 job정의
- 바로 밑에 해당 job의 custom 이름 정의
- 설명 및 어떤 환경에서 돌릴것인지 정의 ubuntu, widnow, mac 등 + 버전까지
jobs:
workflow-test-job:
runs-on: ubuntu-latestStep 정의
- 각 스텝마다 name정의 및 uses(마켓에 있는 action 가져오기)
- market에서 가져오는 경우
{owner}/{repo}@{ref|version}의 형태
- market에서 가져오는 경우
- run은 직접 명령어 실행
jobs:
workflow-test-job:
runs-on: ubuntu-latest
steps:
- name: Checkout repo
uses: action/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v3
with:
node-version: '14'
- name: Install npm
run: npm installGithub Action 사용시 자주 실수하는 것
- github에서 사용하는 PAT(Personal Access Token)
- workflow(Update GitHub Action workflows) 체크하기
- 외부 private repository에 접근할때
- 해당 repo의 secret에 PAT를 넣고 접근을 위해 환경설정 필요
