최종 프로젝트를 진행하며 CI/CD 를 구축해야 한다는 말을 많이 들었어요.

저희 팀은 CI/CD 에 관한 이야기가 나오지 않아 CI/CD 가 뭔지 알지 못하는 채로 프로젝트를 끝내게 되었지만 추후 직접 구축할 수 있을 정도의 지식은 겸비해두고 싶어 주제로 선정하게 되었습니다!

1. I/CD 의 정의

지속적 통합 (Continuous Integration) + 지속적 배포 (Conteinuous Deployment) 을 의미해요.

1-1. CI 란?

빌드 & 테스트 자동화

→ 새로운 코드를 작성하면 자동으로 빌드 & 테스트를 한 뒤 레포지토리에 병합하는 것이 해당돼요.

1-2. CD 란?

배포 자동화

→ CI 를 거친 코드를 실제 운영 서버에 자동으로 배포하는 것이 해당돼요.

1-3. 결론

🧑🏻‍💻 CI/CD 란 빌드 & 테스트 & 배포를 자동화하는 것을 의미해요!

2. CI/CD 의 필요성

그럼 이런 자동화가 왜 필요한 걸까요?

2-1. 코드 변경 & 새로운 코드가 추가 시

기존의 어플리케이션에서 새로운 변화가 생기면 다시 배포를 하기 위해 다음 과정을 거쳐요.

1. 로컬에서 테스트
2. 빌드 파일 생성
3. 빌드 파일 업로드
4. 배포

글로 쓰니까 무척이나 간단해보이지만, 하나씩 진행하다 보면 생각보다 시간이 걸리고 까다로운 과정이에요.

2-2. 수동 테스트의 문제점

저는 제가 담당한 영역에 문제가 없는지, 직접 동작을 확인한 뒤 레포지토리에 코드를 올렸어요.

이렇게 동작 확인 후 Pull Request 을 작성하면 아무 문제가 없을 거라고 생각할 수도 있지만...

두둥... Netlify 는 배포할 수 없는 코드라고 했습니다.

오류가 뜨는 이유는 다양했지만, 어떤 코드를 변경하면 제가 담당하지 않은 코드까지 건드리는 경우가 대부분이었어요.

이렇게, 테스트를 수동으로 진행하다 보면 제가 모르는 에러를 찾기 힘들고 그 에러가 배포된 사이트로까지 이어질 수 있다는 문제점이 있어요.

2-3. 수동 빌드 & 수동 배포의 문제점

저희 프로젝트는 이번에 Netlify 를 사용하여 배포했고, Netlify 가 자동배포를 해주었기 때문에 배포에 관련된 부분을 따로 신경쓰지 않아도 됐어요.

하지만 자동배포를 해주지 않으면 일일이 빌드 작업을 하고, 빌드 파일을 모두 main 브랜치에 올려주는 수고를 해야해요.

저는 졸업작품을 수동으로 배포했는데, 이때 일일이 아래의 명령어를 쳐서 빌드 작업을 해주었어요.

react-scripts build

테스트도 수동이라 안 그래도 큰 위험성을 가진 코드들을 일일이 빌드해서 main 브랜치에 올렸는데, 그렇게 새로 배포된 페이지를 확인해보니 에러가 나면... 😢

저는 졸업작품이었기에 삽질로 끝났지만, 실제 프로덕션에선 아주 큰 일이 발생할 수 있는 일이었어요.

3. CI/CD 적용

그럼 CI/CD 를 어떻게 프로젝트에 사용할 수 있을까요?

3-1. 자동 배포 툴 이용하기

첫번째로는 Netlify 처럼 자동 배포를 해주는 사이트를 이용할 수 있어요.

• Netlify 는 Github 와 연동돼 있기 때문에 소스 코드가 변경되면 자동으로 배포해요.
• 매 PR 마다 코드를 빌드하고, 빌드 프리뷰를 만들어 해당 코드가 빌드 가능한지 아닌지를 판별해주기 때문에 빌드 에러를 방지할 수 있어요.

다만 이렇게 빌드 프리뷰를 만들어 빌드가 가능한지 분석해주는 것은 오로지 빌드 환경에 국한되어 있기 때문에 CI 과정을 대신할 수는 없어요.

3-2. Github action 으로 직접 설정하기

만들어 놓은 테스트 코드가 있고, 새로운 코드가 추가될 때마다 테스트를 자동으로 진행하고 싶다면 Github action 을 사용할 수 있어요.

레포지토리에 특정 이벤트가 발생하면 어떤 작업을 할지 action 을 통해 정의하는 방식이에요.

GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 지속적 통합 및 지속적 배포(CI/CD) 플랫폼입니다.
리포지토리에 대한 모든 풀 리퀘스트를 빌드하고 테스트하는 워크플로를 만들거나 병합된 풀 리퀘스트를 프로덕션에 배포할 수 있습니다.

1. Github Action 들어가기
   우선 레포지토리 안에 있는 Actions 메뉴를 통해서 들어가보면 템플릿이 여러개 존재해요.
   
   이 중에서 직접 세팅이 가능한 템플릿에 들어가 보겠습니다.
2. Yml 파일 작성
   github 의 workflow 는 yml 파일을 통해 작성해요.

	name: CI
	on:
	  push:
    branches: [ "main" ]
	  pull_request:
    branches: [ "main" ]

	jobs:
	  build:
	    runs-on: ubuntu-latest

		steps:
	      - name: Run a one-line script
	        run: echo Hello, world!
	      - name: Run a multi-line script
	        run: |
	          echo Add other actions to build,
	          echo test, and deploy your project.

• name
  해당 워크플로우의 이름을 의미해요.
• on
  워크플로우의 트리거를 설정해요. 예를 들어, 파일에선 push, 와 pull request 이벤트가 main 브랜치로 향하면 동작시켜요. (main 에 push 하거나, main 을 타겟 브랜치로 PR 을 작성하거나)
  
• jobs
  트리거가 발생하면 일어날 일들을 모두 명시해요.
  build
  job 의 이름을 build 로 설정해요.
  runs-on
  어느 환경에서 실행될지에 대해 정의해요.
  steps
  자동으로 실행될 단계별 코드의 이름과 (name) 실행될 코드들을 명시해요. (run)

예를 들어 steps 에서 빌드를 자동으로 실행시키고 싶다면 아래와 같이 작성해요. (여러줄을 쓸 땐 | 기호를 사용해요)

name: build
run: | 
	npm install
	CI= tsc && vite build

그 외에도 환경 변수를 설정하거나, 위와 같이 npm 을 사용하기 위한 NodeJS 버전을 세팅할 수 있어요.