CI/CD

CI/CD는 개발 프로세스

 

CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이

CI (Continuous Integration)

• 버그 수정이나 새로 만드는 기능들이 main repository에 주기적으로 빌드되고 테스트되어서 merge되는 것
• 코드 변경 사항을 주기적으로 빈번하게 (main에) merge해야 한다
  • 한번에 많은 merge conflict를 해결하는 것은 비효율적이고 문제가 생길 수 있기 때문
  • 기능을 작은 단위로 나눠서 개발하고 통합(반영)해야 한다

1. 통합을 위한 단계(build, test, merge)의 자동화
   1. 주기적으로 merge된 코드의 변경사항이 자동으로 빌드되어서, 코드 변경사항 이후에도 빌드가 성공적으로 되었는지 확인되어야 함
   2. 새로 추가된 코드의 변경사항뿐만 아니라 기존 시스템에 다른 버그를 초래하지는 않았는지 자동으로 test까지 되어야 함
   3. CI 원칙을 따르는 개발 프로세스: 코드 리뷰 → main에 merge → 자동으로 팀에서 만든 CI script(CI Server)를 통해서 추가된 코드와 함께 리포지토리가 build되고, build가 잘 된다면 팀에서 작성한 unit test/integration test 등 여러가지 테스트들도 script를 통해 실행됨 → 빌드, 테스트 모두 잘 되어서 green sign 나오면 코드가 통과되어서 나중에 배포할 때 반영 가능 / 빌드 or 테스트가 실패할 경우(red sign) 문제를 일으킨 개발자에게 자동으로 알려줌

• CI 원칙을 따르는 개발 프로세스의 장점
  • 개발 생산성 향상 (주기적인 merge를 통해 merge conflict를 피함)
  • 문제를 빠르게 발견 (merge되는 모든 코드들은 자동으로 빌드/테스트되기 때문에 코드의 결함이나 문제점이 빠르게 발견될 수 있음)
  • 버그 수정 용이 (주기적으로 merge를 하기 위해 코드의 변경사항이 잦기 때문에 문제를 수정할 때도 좀더 고립된 작은 단위의 문제를 확인할 수 있기 때문)
  • 코드 퀄리티 향상 (CI를 잘 운영하기 위해서는 모든 개발자들이 자신이 작성하는 코드에 한해서는 유닛 테스트를 꼭 포함해야 하기 때문 - 소스 코드가 자동으로 테스트될 수 있도록 만듦으로써 조금 더 안정성 있는 제품을 개발)

CD (Continuous Delivery/Deployment)

• 배포 자동화를 위해 고민하는 단계
• CI를 통해 코드 빌드/테스트 과정을 거친 후 배포 단계에서 배포(release)할 준비 과정을 거치고, 준비된(prepared) release가 이상이 없는지 개발자 또는 검증팀이 직접 검증을 한 후 배포 결정이 되면 수동적으로 배포하는 단계가 Continuous Delivery
• 또는 release가 준비되자마자 자동으로 사용자에게 배포할 수 있도록 모든 과정을 자동화해놓는 것이 Continuous Deployment

회사마다 CI/CD의 정도가 다르기 때문에 CI/CD를 한다고 해서 모든 회사가 같은 프로세스를 거치는 것은 x, 회사마다 팀마다 다른 방식으로 적용해서 사용

CI/CD는 완벽히 분리된 것이 아니라 대부분의 회사가 CI와 CD를 거치기 때문에 둘이 묶어서 부르곤 한다

• CI/CD 파이프라인
  • code → build → test → release → deploy
• CI/CD Tools
  • Jenkins, Buildkite, Github Actions, GitLab CI/CD, Bitbucket Pipelines, circleci

 

원본

https://www.youtube.com/watch?v=0Emq5FypiMM