CI/CD란?

이전에 CI/CD에 대해서 정리한 글이 있지만, 한번 더 복습하면서 이해하기 위해 정리 + 적용하는 방법에 대한 글이다.

CI/CD (지속적인 통합/지속적인 제공/지속적인 배포)

CI/CD 적용하기

---

  [ DevOps ]  

DevOps란 개발과 운영을 함께하는 소프트웨어 개발 방법론이다. 소프트웨어 개발 시에는 개발 뿐만 아니라, 빌드/테스트/배포 등 여러가지 과정이 필요하다. 따라서 기존의 회사들은 하나의 서비스를 개발과 운영팀으로 나누어 관리 하였다. 이렇게 하나의 서비스를 개발과 운영으로 나누다 보니 의사결정과 소통에서 비효율적인 문제가 발생했다.

따라서 개발과 운영을 함께 할 수 있는 방법론인 DevOps가 탄생하게 되었다.

 

하나의 서비스를 개발한 후 운영하다 보면 필연적으로 그 서비스는 여러 변경사항이 발생하게 된다.

과거에는 이 변경된 코드를 적용하기 위해서 모든 개발자가 모여 직접 코드를 병합하였다.

 

최근에는 애플리케이션 배포 주기가 짧아 지면서 잦은 코드 병합이 일어나고 이 때마다 여러 개발자가 모여 직접 병합할 경우 생성한 저하라는 문제가 발생하게 되었다. 배포 또한 마찬가지로 여러 서버에서 배포를 진행 해야 한다면 수동으로 배포해야 하기 때문에 실수가 발생할 가능성이 높아지고 특히 서버가 몇 백대라면 수동 배포에 한계가 존재 하게 된다.

 

따라서 통합과 배포를 자동화하여 운영 해주는 DevOps의 CI/CD 개념이 탄생하게 되었다.

 

  [ CI/CD란? ]  

• CI(Contiuos Integration)
  지속적인 통합을 의미하는 용어로 추가 되거나 수정된 코드들을 실시간으로 병합하여 안정적인 배포 파일을 만드는 과정을 의미한다.
• CD(Continuous Delivery && Contiuos Deployment)
  지속적인 제공과 지속적인 배포를 의미하는 용어로 병합된 코드를 자동으로 배포 해주는 과정을 의미한다

  [ CI란? ]  

CI(지속적인 통합)은 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이라고 정의가 쓰여있다.

애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어서 하나의 레포지토리로 관리되는 것을 의미한다.

• SCM(Source Code Management)의 과정도 CI에 속한다.
  - Git을 사용하여 Github Repository 하나로 여러명의 개발자가 소스코드를 올리고 충돌을 처리하는 모든 과정도 CI에 속한다.
  - Git이 아닌 SVN도 마찬가지이다.
• 빌드 후 작성된 테스트 코드를 통해 유효성 검증하는 것도 CI에 속한다.
  - 아주 간단한 예시로 Pull Requrest를 생성 했을 때, 소스코드가 Conflict나는 경우 Merge 버튼이 비활성화 된다.
  그것 또한 유효성 검사에 실패한 것으로 CI에 속한다.
  - 더 나아가, CI 툴을 사용하여 소스코드가 컨벤션에 준수하는 지 등을 체크하는 린터(linter)로 검증을 하도록 할 수 있는 등 다양한 일이 가능하다.

 

  [ CI를 하면 어떤 게 좋을까?? ]  

• 지속적인 통합을 하게 되면 소스코드는 항상 Ready-to-run 상태가 된다. (배포 가능한 상태는 아니다.)
  즉, 중간에 누군가 합류 하게 되더라도 빌드가 되는 코드를 받을 수 있다.
  
  혼자서 개발 할 경우 이런 문제를 겪어보지 못했기 때문에 중요성을 체감 하지 못한다.
  
  하지만, 회사 프로젝트나 오픈소스 프로젝트 등 여러명이 개발하는 상태라면 이 문제는 매우 중요하다.
  중간에 합류해서 새로운 기능을 개발 하려고 하는 데 누군가 작업하고 있는 코드가 아직 공유 Repository에 올라가 있어서 빌드가 안되는 경우가 발생하면 그 개발자와 얘기를 나눠 해결하거나 직접 소스코드를 보면서 디버깅을 해야 한다. 하지만, 이 자체로도 시간이 소요 되기 때문에 생산성이 매우 떨어진다.
  
  게다가 특정한 날을 정해서 각자 개발한 소스코드를 병합하면 그에 따른 많은 시간이 소모된다.
  만약, 기존 코드와 Merge한 코드가 에러가 난다면 이를 처리하는 과정에서 많은 시간이 소요된다.
  
  
• 항상 양질의 코드 퀄리티를 유지 할 수 있다.
  테스트의 자동화를 이루게 되면 항상 테스트 코드를 통과하는 코드만 공유 Repository에 올라 갈 수 있기 때문에 상당한 퀄리티의 소스코드로 유지되게 된다.

  [ CD란? ]  

CD는 지속적 제공(Continuos Delivery), 지속적 배포 (Continuos Deployment)를 모두 의미한다.

• 지속적 제공(Continuos Delivery)
  CI 과정이 모두 끝난 뒤 유효성 검증이 된 코드를 Repository에 올리는 것을 자동화한다.
  (프로덕션 레벨로 배포하는 것과 별개이다.)
  
  항상 프로덕션 레벨로 배포 할 수 있는 준비가 되어 있는 소스코드를 자동으로 올라갈 수 있게 한다.
• 지속적 배포(Continuos Deployment)
  CI/CD 과정의 마지막 단계이다. 지속적 제공을 통해 배포 가능한 소스코드를 프로덕션(생산) 레벨로 릴리즈 하는 것을 의미한다.
  
  실제 사례에서 지속적 배포는 개발자가 애플리케이션을 수정하고 몇 분 이내에 애플리케이션을 자동으로 실행 할 수 있게 하는 것을 의미한다.

  [ CD를 하면 뭐가 좋을까?? ]  

• 개발부터 배포까지 과정이 번거롭지 않고 간소화 되기 때문에 사용자 피드백을 빠르게 반영 할 수 있다.
  장애 대응이 빨라진다. 릴리즈를 했는 데 굉장히 크리티컬한 이슈가 발견 되었을 경우 개발부터 배포까지의 과정이 복잡하면 반영에 오래 걸린다.
• 만약, 로드 밸런서로 수십대의 서버를 동시에 운용한다면?
  자동화를 하지 않았을 경우 직접 서버에 들어가서 일일이 실행 해야 하기 때문에 하루종일 배포 할 수도 있다.