10주차 - CI/CD

• 다음주에 특강이 있어요!

CI/CD

CI(Continuous Integration)

• 지속적 통합

• 빌드/테스트 자동화 과정

• 모든 사람에게 동일 작업 기반을 제공하는 것

• 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장

CD(Continuous Delivery or Continuous Deployment)

• 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포

• 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포

CI/CD를 위한 도구(서비스)

• Jenkins

• CircleCI

• TravisCI

• Github Actions

• …

Github Actions

runner

• 기본적으로 github hosted runner를 사용한다.

• https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

• 즉, ci/cd를 무료로 사용할 수 있음

• 원한다면 self-hosted-runner를 구축해서 사용할 수 있음
https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners

github hosted runner와 self hosted runner를 같이 사용할 수 있을까?

→ self hosted runner를 배포할 instance의 대역폭 혹은 VPC에 위치해놓으면 어떨까?

→ 인증과정이 조금 덜 복잡해지지 않을까?

• 각각의 job에 대한 runner를 따로따로 사용할 수 있음
• lint 수행 job
• tsc 수행 job
• unit test 수행 job
• e2e test 수행 job
• deploy 수행 job

• 패키지 설치가 무척 오래 걸릴 수도 있음
• yarn 2 berry 같은걸 이용하면 zero-install로 관리할 수 있음
• https://toss.tech/article/node-modules-and-yarn-berry
• https://helloinyong.tistory.com/341
• clone 후에 build만 하면 끝이면 좋겠지만, 어쨋든 install을 해주긴 해야됨

Marketplace

• 다른 사람들이 작성한 github actions를 볼 수 있음

• 캠퍼 중 누군가가 ncloud에 배포하는 github actions을 만든다면?
• 서로 다른 팀이지만, 해당 github actions를 같이 운영한다면?
• 오픈소스 느낌으로
• https://smartstudio.tech/custom-github-actions/

Jenkins

• Github Actions는 github hosted runner를 제공하지만, Jenkins는 직접 서버를 구축해야함

• 하지만 Github Actions 보다 범위가 넓고, private 하게 구축해서 사용할 수 있음

• 플러그인이 있음

Github Actions vs Jenkins

고민이 필요한 것들

브랜치 관리 전략

• git flow

• github flow

deploy trigger

• develop

• main

• release

• qa

• hotfix

• …

deploy dispatch

• 직접 배포하는 장치를 만들기

branch protection

• 특정 브랜치에는 push가 되지 않도록 하자
• 관리자만 push 가능
• 반영하기 위해선 PR을 올린 다음에 다수의 사용자가 approve를 해야됨

• PR이 merge되기 전에 head branch는 base branch가 미리 반영 되어 있어야 한다.

git hook

• https://library.gabia.com/contents/8492/

• github에서 무언가 작업을 하기 전에, local에서 한 번 검증해보는 것

• 즉, 안전한 코드만 올리도록 강제할 수 있음

설계를 해본다면?

필요한 것들

• commit 컨벤션

• coding 컨벤션

• 정적 분석
• eslint
• prettier

• 테스트
• 단위 테스트
• 인수 테스트

• 배포
• docker
• k8s
• nginx
• …

빌드/배포 Pipeline

1. 코드 작성
• 코딩 컨벤션에 대해 eslint, prettier 등을 이용하여 강제하도록 만들기

2. commit
• git hook 등을 이용하여 특정 커맨드를 실행해볼 수 있음
• eslint
• tsc
• test
• 전체 코드에 대해 실행하면 너무 오래걸리기 때문에 변경 사항이 있는 파일들에 대해서만 실행해보기

3. push
• main, develop 등 중요 branch에는 직접 push가 안 되도록 github에서 설정하기
• 혹은 git hook에서 관리할 수도 있음

4. Pull Request
• PR을 올렸을 때
• lint, tsc, test 등에 문제가 없는지 확인하는 workflow 실행
• 새로운 commit이 반영되면, workflow 다시 실행
• lighthouse ci 등을 이용해서 성능 측정도 해볼 수 있음
https://fe-developers.kakaoent.com/2022/220602-lighthouse-with-github-actions/
• 리뷰어 지정했을 때
• github hook을 이용하면 리뷰어 지정시 해당 리뷰어에게 알림을 가게 할 수 있음
• 슬랙 봇을 만들어서 지정된 리뷰어에게 알림을 가게 하거나
• 디스코드 봇도 가능
• PR을 머지하기 위해선
• 모든 코드리뷰에 대해 resolve가 되어야 하고
• 최소 1명 이상의 리뷰를 받아야 하고
• test coverage가 일정 수준 이상 되어야 하고
• PR이 머지 되면
• develop에 머지 되는 경우 → qa 환경에 배포
• main에 머지 되는 경우 → production 환경에 배포
• 버전 범핑
• 태깅
• 릴리즈 노트 생성
• 라이브러리 형식의 패키지의 경우, registry에 배포
• 배포가 완료되면(workflow가 끝나면) slack 등을 통해서 알림 메세지 보내기

Health Check

• application이 정상적으로 올라왔는지 확인하기

• 현재 버전, 배포된 시점 등을 같이 보여주면 좋음

• 일정 주기마다 ( 가령 1시간마다 ) app이 정상적으로 실행되고 있는지 자동으로 확인한다면?
• github actions에 cron을 이용하면 가능

Error 추적하기

• Error가 발생할 경우 어떤 방식으로든 알림을 주면 어떨까?

• sentry
• 무료 사용량: 매달 50000개의 에러에 대해 알림을 보내줌. 50000개 초과시 과금
• 잘못하면 1시간 동안 50000개의 에러가 발생할 수도 있음

• slack
• slack bot 등을 이용해서 에러 발생시 알림을 보내줄 수 있음

• 코드상에서 error 관리가 무척 잘 되어있어야 가능

그래서 이런 과정이 왜 필요할까?

• 고민해보자

Reference

• https://grape-wednesday-7ca.notion.site/CI-CD-with-Github-Actions-0e5d255f449846b0be507db6f10c7ac6

• [CI/CD] CI/CD란? - 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment) 기본개념

• https://choseongho93.tistory.com/295

• https://library.gabia.com/contents/8492/