CI/CD란 무엇일까?

오늘은 CI/CD에 대해서 작성해보겠습니다.

 

CI/CD란?

CI/CD는 개발자라면 한 번쯤은 다들 들어봤을 만한 단어일 것입니다.

 

CI/CD는 애플리케이션 개발 단계부터 배포 때까지의 모든 단계를 자동화를 통해서 좀 더 효율적이고 빠르게, 사용자에게 자주 배포할 수 있는 개념입니다.

 

CI/CD의 개념만을 두고 보자면 자동화와 직접적으로 관련은 없을 수도 있습니다. 하지만 그럼에도 불구하고, '자동화'라는 키워드는 CI/CD라는 단어에 거의 항상 따라붙습니다.

 

또한 CI/CD는 DevOps 엔지니어의 핵심 업무라고 불리기도 합니다.

 

 

CI (Continuous Integration)

CI (Continuous Integration)는 "지속적인 통합"이라는 의미를 가지고 있습니다.

 

애플리케이션의 버그 수정이나 새로운 코드 변경 사항이 주기적으로 빌드 및 테스트되면서 공유되는 레파지토리에 통합(merge)되는 것을 의미합니다.

 

그리고 CI는 2가지의 방법(?)이 있는데 이것들을 알아보겠습니다.

 

 

1. 코드 변경사항을 주기적으로 , 자주 merge

하나의 예시를 들어보겠습니다.

개발자들이 하나의 프로젝트를 진행하고 있으며, 형상관리 툴(git, svn 등)을 사용하고 있다고 가정해보겠습니다.

 

또한 그 프로젝트에 2명 이상의 개발자가 협업하고 있습니다.

 

그렇다면, 여기서 개발자들이 자주 통합(merge)하지 않고 2~3일 혹은 더 오랜 기간 동안 각자 개발을 진행한 후, 며칠 동안 작업한 수많은 코드들을 한 번에 merge 한다면 어떻게 될까요? 🤔

 

그렇습니다. 분명 충돌되는 코드들이 다수 발생하게 될 것입니다.

 

이렇게 되면 새로운 기능을 개발하는데 걸리는 시간보다 충돌된 코드들을 수정하는데 더 많은 시간이 소요될 수 있습니다.

그리고 이는 어떤 개발자라도 원하는 상황은 아닐 것입니다. 

 

따라서 가능한 한 작업을 작은 단위로 나누고, 주기적으로 자주 통합해 나가는 것이 중요합니다.

 

 

위의 경우에서의 흐름

1. 개발자들은 계속해서 GitHub 등의 버전 관리 시스템에 코드를 통합한다.
2. 통합한 코드가 정상적으로 작동하는지 빌드 및 테스트를 진행한다.
3. 버그가 발생하면 다음에 처리할 목록에 정리해두고, 다음 날 또는 가능한 시점에 해결한다.

 

 

2. 통합 단계의 자동화

위의 단계는 다 좋은데, "귀찮다"는 단점이 존재합니다.

 

Build와 Test과정은 굳이 사람이 하지 않아도 되는 작업입니다.

 

빈번하게 통합할 때마다 반복해서 진행해야 하는 과정이기 때문에, 한 번에 몰아서 빌드·테스트를 진행하는 것보다 시간이 더 소요될 수 있습니다. 

 

물론 한 번에 테스트를 진행했다가 충돌이나 문제가 발생해 그 코드들을 하나하나 고치는 것보다는 전체적으로 빠를지라도, 당장 그 순간은 귀찮고, 굳이 사람이 할 필요가 없는 작업일 수 있습니다.

 

그렇다면, 여기서 자동화를 도입하면 어떻게 될까요?

GitHub에 코드만 올리면 나머지 작업인 테스트와 빌드는 프로그램이 자동으로 처리해준다면?? 😮

 

이거야말로 반복되는 귀찮은 작업을 하지 않아도 되고, 문제도 줄어드는 훨씬 편한 방법이 될 수 있습니다.

 

이렇기 때문에, CI/CD의 개념상 자동화가 필수는 아니더라도 항상 자동화라는 키워드가 함께 언급되는 이유입니다.

 

 

자동화를 적용한 후의 흐름

1. 위와 동일하게 개발자들은 형상관리 툴(GitHub 등)에 작업한 코드를 통합한다.
2. 빌드 및 테스트는 자동으로 진행되므로, 버그가 생기면 다음날 확인해서 버그를 해결한다.

 

위의 흐름을 보면 알 수 있듯이, 앞서 언급했던 귀찮고 반복적인 작업은 자동화를 통해서 생략할 수 있으며 시간도 절약되고 작업도 단순해지는 효과를 볼 수 있습니다.

 

CI의 장점

• 코드의 검증에 소요되는 시간이 줄어든다.
• 개발 편의성이 향상된다.
• 항상 테스트 코드를 통과한 코드만 레포지터리에 올라가기 때문에, 코드 퀄리티를 높게 유지할 수 있다.

 

 

CD (Continuous Delivery / Continuous Deployment)

CD는 "Continuous Delivery, 지속적인 제공"이라는 의미와 "Continuous Deployment, 지속적인 배포"라는 두 가지 의미를 가지고 있습니다.

 

CI에서 Build와 Test가 완료된 후, 배포 단계에서 릴리스 준비가 되었는지, 그리고 문제가 없는지를 검토하는 과정을 거칩니다.

 

이 과정을 통해 나온 결론이 "이제 사용자들에게 서비스를 제공해도 되겠다!"라는 결론이 나게 되면, 수동적으로 배포를 진행하게 되는데, 이것이 "Continuous Delivery, 지속적인 제공"입니다.

 

반면에, 준비가 완료되자마자 자동화를 통하여 곧바로 배포를 진행하는 경우를 "Continuous Deployment, 지속적인 배포"라고 부릅니다.

 

 

CD를 적용한 후의 흐름

1. CI를 적용하여 코드를 검증한다.
2. 실제 배포 환경과 비슷한 환경에서 검증을 진행한다.
3. 검증된 소프트웨어를 실제 프로덕션 환경으로 배포한다.

 

CI/CD는 어느 정도의 자동화를 하냐에 따라 조금씩 다르기 때문에, CI/CD라고 해서 모두 동일한 구조를 갖는 것은 아닙니다. 회사나 팀에 따라 구성이나 적용 방식이 달라질 수 있습니다.

 

 

 

CD의 장점

• 개발자는 배포보다는 개발에 더욱 집중할 수 있도록 도와준다.
• 개발자가 원클릭으로 수작업 없이 빌드, 테스트, 배포까지의 자동화를 할 수 있다.

 

 

공부한 지식을 바탕으로 정리해서 글을 작성합니다.
다시 복습할 때 보기 위해 정리하지만, 읽으시는 분들께도 도움이 되면 좋겠네요 :)
틀린 내용이나 오타가 있으면 지적해주시면 감사하겠습니다!

 

 

 

Reference

QA CI/CD란?

엘리님 유튜브 - CI/CD 5분 개념 정리

CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정