[프론트엔드 전반] CI/CD

신재욱·2023년 9월 13일
post-thumbnail

CI

CI는 간단히 요약하자면 빌드/테스트 자동화 과정 CI는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다. CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

개발자가 직접 코드를 병합하고 빌드, 테스트를 검증하는 것은 시간이 많이 소요될 뿐만 아니라 귀찮고 그 양도 프로젝트의 크기가 커질수록 많아질 수밖에 없다.

이를 자동화하면 개발자가 빌드와 테스트를 직접 하지 않고도 수정한 코드를 브랜치에 병합하기만 하면 자동으로 빌드와 테스트를 검증할 수 있다.

CI의 간단한 순서

  • 개발자가 구현한 코드를 기존 코드와 병합한다.
  • 병합된 코드가 올바르게 동작하고 빌드되는지 검증한다.
  • 테스트 결과 문제가 있다면 수정하고 다시 1로 돌아간다. 문제가 없다면 배포를 진행한다.

CD

CD는 간단히 말하면 배포 자동화 과정이다. CD는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올립니다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포됩니다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있습니다.

CI/CD 종류

  • Jenkins
  • CircleCI
  • TravisCI
  • Github Actions
  • etc

CI/CD 적용 전과후 비교

CI/CD를 적용하기 전

  • 개발자들이 개발하여 코드를 수정
  • 각자의 feature 브랜치에 코드를 push
  • 각자의 코드를 git에 올리고 통합
  • 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어느 부분에 에러가 있는지 디버깅하고 코드를 수정
  • 위의 과정을 반복
  • 많은 시간을 할애하여 에러가 해결되었으면 배포를 시작 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간을 소요

CI/CD를 적용 후

  • 개발자들이 개발하여 feature브랜치에 코드를 push
  • git push를 통해 Trigger되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송
  • 개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러부분을 수정하고 코드를 master 브랜치에 merge
  • master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행이 되었다면 CI서버에서 알아서 Deploy 과정을 수행

참고

profile
3년차 개발자

0개의 댓글