본문 바로가기
IT/Teckweek

CI/CD

by YEON-DU 2022. 10. 6.
반응형

CI (Continuous Intergration) / CD (Continuous Deployment)

CI/CD란?

CI/CD라는 말을 들어봤는가?

사실상 큰 프로젝트를 진행하지 않았다면 조금 낯선 용어일 수도 있다.

그러나 보통 회사에서 프로젝트에 참여하면, CI/CD를 직접 설정하여 꾸준히 진행하는 경우가 많다.

CI/CD라는 건 뭘까?

용어를 직역하자면 지속적 통합과, 지속적 배포이다.

말 그대로 커밋된 소스코드를 지속적으로 합치고, 배포하는 과정을 의미하는 것이다.

조금 더 자세히 알아보자.

CI란?

빌드/테스트 자동화 과정이다.

CI는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.

CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 Repository에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

CI는 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다.

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

CD란?

배포 자동화 과정이다.

CD는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하고, 두 용어는 상호 교환적으로 사용된다.

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 자동화 정도를 설명하기 위해 별도로 사용되기도 한다. (= CD가 완료되어 커밋이 이루어졌다면 정상적인 상태이고, 아니라면 어딘가 기존 파이프라인과 맞지 않는 코드가 존재한다는 것을 확인할 수 있다.)

 

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

 

아마 여기까지 읽어도 CI/CD를 경험해보지 못했다면 그게 뭔가? 라는 생각이 들 것이다.

그렇다면 내 경험담을 조금 요약해서 와닿게 설명해보자.

 

내가 CI/CD를 자동화할 필요하다고 느꼈던 부분은 이런 부분이다.

  1. 일정한 빌드 세팅으로 매번 빌드해야 할 때
  2. 특정 빌드 별 세팅이 따로 존재해서 매번 다르게 세팅해야 할 때 (앱 개발의 경우 Release 버전, Debug 버전, 서버가 따로 있다면 A 서버 버전 … 등등)

이럴 때 빌드별 세팅이 버튼 하나로 자동화 되어 클릭하면 해당 세팅대로 빌드되는 것이 있으면 좋지 않을까?

이게 바로 CI/CD의 기본 개념이다.

 

조금 더 편한 이해를 위해 예시를 하나 더 들어보자.

실제 CI/CD가 존재하지 않을 때의 과정의 과정은 이렇다. (보통 혼자 하는 프로젝트도 동일하다)

1. 개발자들이 개발하여 코드를 수정합니다.

2. 각자의 feature 브랜치에 코드를 push합니다. (but, 어느 한 부분에서 에러가 났지만 개발자들은 눈치채지 못합니다.)

3. 각자의 코드를 git에 올리고 통합(Intergration)합니다.

4. 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어디부분에 에러가 있는지 디버깅하고 코드를 수정합니다.

5. (1) ~ (4)의 과정을 반복합니다.

6. 많은 시간을 할애하여 에러가 해결되었으면 배포를 시작합니다. 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간을 소요합니다.

 

CI/CD가 존재할 때는 다음과 같다.

 

1. 개발자들이 개발하여 feature브랜치에 코드를 push합니다.

2. git push를 통해 Trigger(Trigger는 push가 아니라 다른 옵션을 줄 수도 있다)되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송합니다.

3. 개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러부분을 수정하고 코드를 master 브랜치에 merge합니다.

4. master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행이 되었다면 CI서버에서 알아서 Deploy 과정을 수행합니다.

 

코드 양이 방대해지고, 참여하는 개발자가 많아질 수록 이러한 자동화테스팅, 빌드 과정은 정말 중요하다.

 

실제로 내가 다녔던 대부분의 회사들은 CI/CD를 활용하고 있고, CI/CD를 만드는 툴은 무적 다양하다. 이를테면 아래와 같은 경우가 있다.

CI/CD 종류

  • Jenkins
  • CircleCI
  • TravisCI
  • Github Actions
  • etc

 

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

반응형

'IT > Teckweek' 카테고리의 다른 글

BlendMode  (0) 2022.11.05
SCM (Software Configuration Management)  (0) 2022.10.26
로드밸런싱  (0) 2021.06.10
Reactive Programing이란?  (0) 2021.04.28
프로세스와 스레드  (0) 2021.04.25

댓글