CI는 어디에 쓰일까?
- 타입 체크
- 빌드 확인
- Lint 검사
- Test 코드
등의 검사를 할 때 사용 된다.
왜 필요할까?
매번 개발자가 코드를 수정하고, 빌드와 테스트를 하고 배포를 한다면 상당히 많은 시간이 소요되는데, 이것을 CI와 CD로 자동화시킨다면, 시간을 단축시키고, 개발에 더 많은 시간을 투자할 수 있다.
또한, 다른 사람들이 이 코드가 제대로 동작하는지 한 눈에 알아볼 수 있어서 좋다.
그래서 CI가 무엇일까?
CI는 빌드 / 테스트 자동화 과정이다.
개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다.
CI를 이용하여 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.
지속적 통합의 실행은 소스 / 버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작된다.
커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장할 수 있다.
CD란?
CD는 배포 자동화 과정이다.
지속적인 서비스 제공 또는 지속적인 배포를 의미하며 이 두 용어는 상호 교환적으로 사용된다.
지속적인 제공 - 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 레포지토리에 자동으로 업로드되는 것을 뜻한다.
실시간 프로덕션 환경으로 배포할 수 있도록 해준다.
지속적 배포 - 개발자의 변경 사항을 레포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스 하는 것을 의미한다.
=> 수동 프로세스로 인한 과부하 문제를 해결할 수 있다.
간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포된다.
강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도 여러 번 이루어지는 릴리스가 특별하지 않은 일상이 된다.
CI / CD 종류
- Jenkins
- CircleCI
- TravisCI
- Github Actions
등이 있다.
Github Actions를 이용하여 CI/CD를 구축해보자
Github Action이 무엇일까?
Github Actions란 소프트웨어 개발 라이프사이클 안에서 Pull Request, Push 등의 이벤트 발생에 따라 자동화된 작업을 진행할 수 있게 해주는 기능이다.
- CI/CD로컬 레포지토리에서 원격 레포지토리로 푸쉬하고 난 후, Github Actions에서는 이벤트 발생에 따라 자동으로 빌드 및 배포하는 스크립트를 실행시켜주는 것입니다.
- 애플리케이션의 규모가 클수록 빌드, 배포 시간이 오래걸리는데 이를 자동화시켜놓으면 해당 시간을 낭비하지 않을 수 있겠죠.
- 이 글의 작성 목적이자 Github Actions을 활용하는 가장 대표적인 예시 중 하나입니다.
- Testing따라서 테스트 성공 여부에 따라서 자동으로 PR을 Open 및 Close 할 수 있습니다.
- 팀 프로젝트를 진행하다가 Pull Request를 보내면 자동으로 테스트를 진행하는 것또한 Github Actions으로 구현할 수 있습니다.
- Cron Job매일 특정 시간이 되면 크롤링 작업을 진행한다는 등의 예시가 존재합니다.
- Github Actions를 통해 특정 시간대에 스크립트를 반복 실행하도록 구현할 수 있습니다.
Github Action의 구성요소
Github Actios을 활용하기 위해 알아야 할 구성요소들이 있다.
Workflow
- 레포지토리에 추가할 수 있는 일련의 자동화된 커맨드 집합이다.
- 하나 이상의 Job으로 구성되어 있으며, Push나 PR과 같은 이벤트에 의해 실행될 수도 있고, 특정 시간대에 실행될 수도 있다.
- 빌드, 테스트, 배포 등 각각의 역할에 맞는 Workflow를 추가할 수 있고, .github/workflows 디렉토리에 YAML 형태로 저장한다.
Event
- Event란 Workflow를 실행시키는 Push, Pull Request, Commit등의 특정 행동
Job
- 동일한 Runner에서 실행되는 여러 Step의 집합
- 하나의 Workflow 내의 여러 Job은 독립적으로 실행되지만, 필요에 따라 의존 관계를 설정하여 순서를 지정해줄 수 있다.
- 테스트 Job은 반드시 빌드Job 이후에 수행되어야 하는데, 여기서 의존 관계를 설정해 빌드 Job이 성공적으로 끝나야 테스트 Job을 수행할 수 있도록 지정할 수 있다.
Step
- 커맨드를 실행할 수 있는 각각의 Task를 의미한다.
- Shell 커맨드가 될 수도 있고, 하나의 Actios이 될 수 있다.
- 하나의 Job 내에서 각각의 Step은 다양한 Task로 인해 생성된 데이터를 공유할 수 있다.
Action
- Action이란 Job을만들기 위해 Step을 결합한 독립적인 커맨드로, 재사용이 가능한 Workflow의 가장 작은 단위의 블럭이다.
- 직접 만든 Action을 사용하거나 Github Community에 의해 생성된 Action을 불러와 사용할 수 있습니다.
Runner
- Runner란 Github Actions Workflow 내에 있는 Job을 실행시키기 위한 애플리케이션이다.
- Runner Application은 Github에서 호스팅하는 가상 환경 또는 직접 호스팅하는 가상 환경에서 실행 가능하며, Github에서 호스팅하는 가상 인스턴스의 경우에는 메모리 및 용량 제한이 존재한다.
레포지토리에서 Actions 탭에서 자신의 환경을 선택하던지, 없다면 아래 빨간색 네모박스를 눌러주면된다.
잘챙기짐 프로젝트에서 Lint와 build ci를 하나로 만들어본 코드는 다음과 같다.
# ci 이름
name: build ci
on:
# push 할 때 실행시키겠다 (pull_request 도 가능)
push:
# 브랜치 지정
branches:
- develop
jobs:
# Job이름으로, build라는 이름으로 job 표시
build:
# Runner가 실행되는 환경 정의
runs-on: ubuntu-latest
steps:
# uses 키워드를 통해 Action을 불러올 수 있다.
# 여기에서는 해당 레포지토리로 check-out하여 레포지토리에 접근할 수 있는 Action
- uses: actions/checkout@v3
# 노드
- uses: actions/setup-node@v3
with:
# 노드 버전 지정
node-version: '16'
# job이름
- name: package install
# shell 실행 명령어
run: yarn install
- name: build
run: yarn build
- name: Lint
run: yarn lint
run에는 하나의 커맨드가 아닌 커맨드도 실행이 가능하다
run : |
yarn install
yarn build
yarn lint
name을 하나로 만들면 위처럼 작성하면 된다.