CI / CD 의 배경
혼자 개발을 할 경우, 본인에게 맞는 툴을 사용하여 직접 배포 하면 된다. 하지만 문제는 ‘개발은 혼자 하지 않는다는 것’이다. 여러 개발자들은 테스트 서버에서 작업을 하고, 운영 서버에 배포를 하는 과정을 거친다. 만약 개발자 한명이 테스트 코드가 없거나, 검증되지 않는 코드를 배포를 하게 된다면, 다른 개발자들은 본인의 개발 환경에서 작동하지 않는 경우가 생긴다. 그 상태로 운영서버에 배포하게 될 경우 사용자는 에러를 접하게 된다. 이러한 문제들을 해결하기 위해 나타나나 것이 CI/CD이다.
CI / CD (지속적인 통합 : CI , 지속저인 배포 : CD)
코드 구축부터 시작해서 배포까지의 일련의 과정들을 CI/CD 파이프라인이라고 한다.
- CONTINUOUS INTERGRATION : 코드를 빌드하고 테스트하고 합친다. (BUILD → TEST → MERGE )
- CONTINUOUS DELIVERY : 해당 레퍼지토리에 릴리즈한다. (최종 코드 산출물 저장)
- CONTINUOUS DEPLOYMENT : 이를 운영 서버, 즉 실제 서비스에 배포한다.
CI / CD 의 장점
-
코드 배포까지의 과정을 좀 더 체계적으로 만들 수 있다.
배포 과정에서 문제가 생기게 되면 빠르게 문제의 위치를 파악 할 수 있다.
-
테스트를 강제할 수 있다.
테스트가 없으면 코드 머지자체가 안되게 만들 수도 있다.
빌드
대표적인 예로 webpack이 있다. webpack은 여러가지 모듈들을 정적 자산으로 바꿔주는, 즉 빌드를 도와주는 도구이다.
예를 들어 vue 프로젝트를 만든다고 가정해보자. vue 프로젝트의 개발환경에서는 .vue라는 확장자를 가진 파일을 수정해야한다. 하지만 이 .vue 확장자는 웹브라우저에서 구동될 수 없다. 웹 브라우저에 보여지기 위해서는 html, js, css만 가능하기 때문이다. 만약 배포를 하게 되면 빌드의 과정을 거치게 되는데, 빌드를 하게 되면 .vue 라는 확장자가 html, js, css로 바꿔진다.
즉, 웹브라우저에서 사용할 수 없는 확장자들로 이루어진 모듈들을 웹브라우저에서 사용할수 있게 바꿔주는 것을 빌드라고 한다.
테스트
테스트는 함수 등 작은 단위를 테스팅하는 단위테스트, 모듈을 통합할 때 테스트하는 통합테스트, 사용자가 서비스를 사용하는 상황을 가정해서 테스트하는 엔드투엔드테스트(E2E)가 대표적이다.
테스트를 위한 대표적인 프레임워크로는 mocha가 있다. mocha는 테스트 코드를 실행해켜주는 Nodejs 테스트 프레임워크로 테스트를 위한 다양한 기능을 제공해준다.
머지
git을 이용해 여러명의 개발자가 개발한 코드를 합친다. 작은 프로젝트 같은 경우는 충돌을 최소화하기 위해 어떤 폴더는 해당 개발자만 맡기도 한다. 하지만 충돌은 대부분 일어나기 때문에 조금 더 작은 단위로 충돌이 일어나게 하는게 중요하다.
한달동안의 코드를 짜서 배포하는 게 아니라, 작은 이슈 단위로 나눠서 머지를 한다. (그렇다고 너무 아토믹하게 작은 단위로 하는 것 보다는 이슈 단위를 기반으로 하는게 좋다.)
만약 충돌 시 서로 화면 공유를 하며 합의하에 충돌을 해결하는 것이 좋다. (줌이나 구글 미트를 이용)
배포
배포는 사용자를 위한 서비스를 배포할 수 있지만 그 뿐만 아니라 내부적인 QA엔지니어, 관리자페이지 를 위한 배포, 데이터웨어하우스로부터 데이터를 가공해서 백엔드 개발자를 위한 배포 등을 포함한다.
github action, genkins, circle ci가 유명하며 heroku를 통해서 CI, CD 설정 없이 자동으로 가능한다.
heroku + github action으로 설정도 가능하다.
깃허브 Actions
특정한 이벤트가 발생했을 때 내가 원하는 일을 자동으로 수행할 수 있게 만들어 주는 툴이다.
Events
깃허브에서 발생할 수 있는 대부분의 이벤트를 지정할 수 있다.
예를들어 PR을 main 브런치에 머지할 때 어떤 테스트를 수행해야 하거나, 커밋을 깃허브에 푸쉬하거나, 새로운 이슈를 만들 경우를 지정한다.
Workflows
즉, 특정한 이벤트가 발생했을 때, 내가 어떤 일을 수행할 지, 자동화 할 지 명시할 수 있다.
예를 들어, 푸쉬라는 이벤트가 발생하면 workflows에 지정된 것들이 수행될 것이다.
Jobs
workflows안에 하나, 또는 다수의 job을 정의 할 수 있다. 하나의 job은 무언가를 한다. 예를 들어 job 하나는 unit test를, 또다른 job 하나는 E2E test를 할 수 있다. 기본적으로 병렬적으로, 동시 다발적으로 실행이 되며, 순차적으로도 만들 수 있다.
각각의 job안에는 어떤 순서대로 job이 실행되어야 하는지 step을 명시해 줄 수 있다. shell script 또는 npm 명령어를 수행할 수 있다.
Actions
깃허브에서 제공해주는 유용한 actions을 가져다 쓸 수 있다.
예를 들어 action check out은 레포지토리에 올려둔 코드를 서버로 내려받은 후 특정 브랜치에 전환하는 명령어이며, action setup node는 자동적으로 노드 환경을 설정하기 위한 명령어이다.
Runners
job을 실행하는 것을 runner라고 한다. vm머신, docker container라고 생각하면 된다. 각각의 job은 개별적이고 독립적인 runner라는 container에서 실행된다고 보면 된다.
깃허브 Actions 사용해보기
.github/workflows 폴더 안에 workflow.yml 파일을 만든다.
어떤 workflow 인지에 따라 이름을 지정해주면 된다.
name: CI #어떤 워크 플로우 인지
on:
push:
branchs: ["main"] #어떤 이벤트가 발생했을 때 workflow가 실행되는지
jobs:
check-bats-version: #어떤 일을 수행하는지 job 이름
runs-on: ubuntu-latest #어떤 러너를 사용할지, 어떤 vm 머신을 사용할 지
steps: #어떤 순서대로 job을 실행할지
- name: actions/checkout@v3 #github에서 제공하는 checkout actions을 사용할거야
- uses: actions/setup-node@v2 #github에서 제공하는 노드를 세팅하는 actiosns도 사용할거야
with:
node-version: "14" #노드 버전 명시
- run: npm install -g bats #원하는 명령어 사용
- run: bats -v