CI/CD 개념정리

프로젝트/프로젝트 관련

CI/CD 개념정리

Wonuk 2021. 12. 28. 18:48

본 포스팅은 유튜브를 기반으로 만들어졌습니다.
https://www.youtube.com/watch?v=0Emq5FypiMM

CI/CD 개요

요즘같이 빠르게 진화하고 변화하는 시대에 어떻게하면

시장과 고객의 요구에 빠르게 반영해서 제품을을 출시, 업데이트 할 것인가는

큰 과제입니다.

바로 이것을 위해서 세계적으로 많은 기업들이 CI/CD를 개발 프로세스로 사용합니다.

대부분의 회사에서 CI/CD 환경에서 일하고 있기 때문에

정확하게 어떤 역할을 하는지 알고있어야 합니다.

CI/CD란?

어플리케이션 개발 단계부터 배포까지 모든 단계들을

자동화를 통해서 조금 더 효율적이고 빠르게 사용자에게 빈번이 배포할 수 있도록

만드는 것을 말합니다.

CI(Continuous Integration) - 지속적인 통합

CD(Continuous Delivery) - 지속적인 제공

CD(Continuous Deployment) - 지속적인 배포

CI(Continuous Integration)란? 지속적인 통합

버그 수정이나 새로 만드는 기능들이 매일 Repository에 주기적으로 빌드되고

테스트가 되어서 Merge 되는것을 말합니다.

이 방식은 1991년 Grady Booch에 의해서 사용되어 지다가

나중에는 extream programming 개발 방법론에서 채택되어 졌습니다.

Grady Booch는 객체지향과 관련된 책을 쓴 아주 유명한 저자입니다.

이 CI는 두가지를 포인트로 잡고 생각하면 편합니다.

1. 코드 변경사항을 주기적으로 빈번하게 머지해야 한다.

개발자들은 그들의 코드 변경사항을 매일 주기적으로 빈번하게 머지해야 한다.

동일한 소스파일 위에서 두명의 개발자가 서로다른 코드를 작성하고 있다가

오랜기간 후 머지를 하려고하면 서로다른 코드를 어떻게 통합하여 적용할 것인지

고생을 많이하게 됩니다.

이렇게되면 새로운 기능을 위해서 코드를 작성하는 시간보다 머지 충돌을 해결하기 위해서

더 많은 시간을 사용하게 됩니다.

그렇기때문에 버그를 수정하거나 새로운 기능을 구현할 때는 더더욱 어떻게 작은 단위로

나누어서 메인 Repository에 반영하거나 사용자에게 배포할 수 있을지 최대한 작은 단위로

나누어서 개발하고 통합해 나가는것이 중요합니다.

2. 통합을 위한 단계(빌드, 테스트, 머지)의 자동화

주기적으로 Merge된 코드의 변경 사항이 자동으로 빌드가 되어서

코드 변경사항 이후에도 빌드가 성공적으로 되는지 확인이 되어야 하고

새로 추가된 코드의 변경사항 뿐만 아니라 기존의 시스템에 다른 버그를 초래하지는 않았는지

자동으로 테스트까지 되어야 합니다.

모든 테스트가 통과되면 그린 사인이 나오며 배포에 반영이되고

새로 추가된 코드에 문제가 있어서 빌드가 실패하거나, 테스트가 실패한다면

레드사인이 발생하며 문제를 일으킨 개발자에게 자동으로 알려줍니다.

이렇게 CI원칙을 따라가면 어떠한 장점이 있을까요?

1. 주기적인 머지로 머지의 충돌을 피할 수 있습니다. 개발 생산성 향상

2. 문제점을 빠르게 발견합니다. 자동으로 빌드되고 테스트되기 때문에 빠르게 문제점을 찾습니다. 빠른 수정가능

코드의 변경사항이 작기때문에 문제를 수정할때도 조금 더 고립된 작은 단위의 문제를 확인할 수 있기 때문

3. 이러한 장점들을 통하여 코드의 퀄리티가 향상됩니다.

CI를 잘 운영하기 위해서는 모든 개발자들이 자신이 새로 작성하는 코드에 한해서는

유닛 테스트를 꼭 포함 해야하기 때문입니다.

그래서 CI를 사용한다면 우리 프로젝트의 대부분이 자동으로 테스트 되도록 만들기 때문에

조금 더 안정성 있는 제품을 개발 할 수 있습니다.

CD(Continuous Delivery), (Continuous Deployment) - 지속적 제공, 배포

위 두가지는 각각 서로 연관이 있고 섞어서 함께 사용하는 경우도 있습니다.

그래서 비슷하다고 생각하면 됩니다.

두가지 모두 마지막 배포단계에서 어떻게하면 자동화해서 이 배포를 만들 수 있을지를

고민하는 단계입니다.

CI를 통해서 주기적으로 머지된 코드의 변경사항들이

자동으로 빌드가되고 테스트가 되었다면 이제 배포하는 단계에서

배포(Release)할 준비과정을 거치고 여기에서 준비된 Release가 괜찮은지

아무런 문제가 없는지 직접 개발자 또는 검증팀이 검증한 다음

최종적으로 배포하게 되겠다고 판단되면

수동적으로 배포하는 단계를 Continuous Delivery 라고 합니다.

또는 Release가 준비가 되자마자 자동으로 사용자에게 배포되도록 만들 수 있는데

이렇게 모든 과정을 자동화 하는것을 Continuous Deployment 라고 합니다.

Delivery와 비슷하지만 최종단계에서 자동화가 되었는가 안되었는가에 따라서

조금씩 다릅니다.

이런 모든 과정들을 어떻게 자동화 해두냐, 어떻게 스크립트를 쓰느냐,

이 자동화와 테스팅에 대해서 얼마나 자신감이 있느냐에 따라서

어떤 회사들은 최종단계는 수동적으로 릴리즈하는 경우도 있고

자동적으로 릴리즈 하는 경우도 있습니다.

회사마다 어느정도의, 얼마만큼 자동화 하는지가 다르기 때문에

CI/CD라고 해서 모든 회사가 똑같은 프로세스를 거치는것은 아닙니다.

즉, 회사마다, 팀마다 다른 방식으로 적용해서 사용할 수 있습니다.

CI/CD

앞서 설명한것처럼 CI/CD가 완벽히 분리된것이 아니라

대부분의 회사에서 CI/CD를 거쳐서 배포하기 때문에

CI/CD라고 묶어서 얘기합니다.

정리

개발자가 작은단위로 기능을 나누어서 주기적으로 Main Repository에 Merge를 하면

자동으로 빌드를하고 테스트 과정을 거쳐서 릴리즈 준비를 하고

여기서 수동 혹은 자동으로 최종 배포를 하게됩니다.

CI/CD를 위한 다양한 툴

회사마다 다른 툴을 사용하기 때문에 어떤 툴을 사용하는지 알아보고

그 툴에 대해서 정확하게 알아보고 공부하면 좋습니다.