ci cd 란?

들어가며

요즘같이 바르게 진화하고 변화하는 시대에 어떻게 하면, 시장과 고객의 요구에 빠르게 반응해서 제품을 출시, 업데이트할 것인지가 큰 과제입니다.

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

대부분의 회사에서 CI/CI 환경에서 일하고 있기 때문에 개발자이거나 소프트웨어제품에 관련된 일을 한다면, CI/CI 가 무엇인지 정확히 알아두어야 합니다.

 

CI / CD 란?

CI / CD 란 어플리케이션 개발 단계부터 배포때까지 모든 단계들을 자동화를 통해서 조금 더 효율적이고 빠르게 사용자에에게 빈번히 배포할수 있도록 만드는 것을 말합니다.

CI 는 Continuous Integration, 지속적인 통합의 약자고, CD 는 Continuous Delivery, 지속적인 제공의 약자이면서 Delivery 를 대신해 Deployment, 배포로 사용하는 경우도 있니다. 

 

CI 

버그 수정이나 새로 만드는 기능들이 main 레포지토리에 주기적으로 빌드되고, 테스트가 되어서 merge 되는 것을 말합니다. 이 CI 는 두 가지 포인트로 생각하시면 됩니다.

개발자들은 그들의 코드 변경사항을 main 레포지토리에 주기적으로 빈번하게 merge 를 해야합니다.

 

동일한 소스파일 위에서 두 명의 개발자가 서로 다른 코드를 작성하고 있다가 오랜 기간 서로 변경을 하다가 나중에 merge 를 하려고 하면, 서로 다른 코드를 어떻게 통합해서 적용해 나갈 건지 고생을 하게 됩니다. 이렇게 되면, 새로운 기능을 위해서 코드를 작성하는 시간보다 merge 충돌을 해결하기 위해서 더 많은 시간을 사용해야 할지도 모릅니다.

그렇기 때문에 버그를 수정하거나 또는 새로운 기능을 구현할 때에는 더더욱 이 기능을 어떻게 작은 단위로 나눠서 내가 main 레포지토리에 반영하거나 또는 작은 단위로 나눠서 내가 사용자에게 배포할 수 있을지 최대한 작은 단위로 나눠어서 개발하고 통합해 나가는 것이 중요합니다. 

 

CI 에 더 중요한 두 번째 포인트는,

통합을 위한 단계(build, test, merge)의 자동화입니다.

 

주기적으로 merge 된 코드의 변경사항이 자동으로 build 가 되어서 코드 변경사항 이후에도 build 가 성공적으로 되는지 확인이 되어야 하고, 새로 추가된 코드의 변경사항 뿐만 아니라 기존의 시스템에 다른 버그를 초래하지는 않았는지 자동으로 테스트까지 되어야 합니다. 

보통 개발팀에서 이런식으로 셋업을 많이 하는데, main 레포지토리가 있고, 개발자들은 하루에도 몇 번씩 주기적으로 코드의 변경사항을 main 레포지토에 merge 를 합니다. 물론 그 전에 코드리뷰를 통해 적절한지 확인을 받아야 할 겁니다. 이렇게 merge 가 되었으면, 자동으로 팀에서 만든 ci 스크립트를 통해서 추가된 코드와 함께 해당 레포지토리가 build 가 되고, build 가 잘 된다면, 팀에서 작성한 유니테스트, 인티그레이션 테스트 등등 여러가지 테스트들도 스크립트를 통해서 실행이 됩니다.

이렇게 build 도 잘 되고, test 가 잘 되어서 'green' 이라는 초록색 사인이 나오면, 무사히 통과가 되어서 나중에 배포할 때 반영이 될 수도 있고, 새로 추가된 코드에 문제가 있어서 build 가 실패하거나 또는 build 는 성공했는데 test 에서 실패한다면, 빨간색, red 사인이 뜨면서 문제를 일으킨 개발자에게 자동으로 알려줍니다. "A 개발자님 방금 merge 한 코드에 red 사인이 떴으니 확인을 해보세요" 라고요.

이렇게 CI 원칙을 따라갔을 때, 장점들은 다음과 같이 있습니다.

• 주기적으로 merge 를 하기 때문에 merge 충돌을 피할 수 있어서 개발의 생산성을 높임.
• merge 되는 코드들은 자동으로 build 되고, test 되기 때문에 코드의 결함이나 문제점이 빠르게 발견됨.
• 주기적으로 merge 를 해서 코드의 변경 사항이 작기 때문에 문제를 수정할 때도, 조금 더 고립된 작은 단위의 문제를 확인할 수 있어서 발견된 결함은 빠르게 수정이 가능함.
• 이런 장점들을 통해서 조금 더 나은 코드의 퀄리티를 가질 수 있음.

ci 를 잘 운영하기 위해서는 모든 개발자들이 자신이 새로 작성한 코드에 한해서는 uni-test 를 꼭 포함해야하기 때문입니다. 그래서 ci 를 사용한다면, 프로젝트의 대부분의 소스코드들이 자동으로 test 가 될 수 있도록 만들기 때문에 조금 더 안정성 있는 제품을 개발해나갈 수 있습니다.

 

 

CD

지속적 제공, 지속적 배포, 두 가지 모두 다 마지막 배포단계에서 어떻게 하면 자동화해서 배포를 만들 수 있을지에 대해 고민하는 단계입니다. ci 를 통해서 주기적으로 merge 된 코드의 변경사항들이 자동으로 build 되고, test 되었다면, 배포하는 단계에서 release(배포)할 준비 과정을 거치고, 준비된 release 가 괜찮은지, 정상적인지, 아무런 문제가 없는지 직접 개발자나 도는 검증 팀이 검증을 한 다음에 최종적으로 사용자에게 배포해도 되겠다 라고 결정이되면 수동적으로 배포하는 단계를 Continuous Delivery 라고 합니다. 또는 release 가 준비가 되자마자 자동으로 사용자에게 배포할 수 있도록 만들 수도 있는데요. 이렇게 모든 과정을 자동으로 해놓은 것을 Continuous Deployment 라고 합니다. Delivery 와 살짝 비슷하지만, 최종 단계의 자동 여부에 따라 달라질 수 있습니다.

이런 모든 과정들을 어떻게 자동화로 해두는지, 어떻게 스크립트를 쓰는지, 그리고 이 자동화와 test 에 대해서 얼마나 자신감이 있느냐에 따라서 어떤 회사들은 최종단계는 수동적으로 release 가 있고, 어떤 회사는 자동적으로 release 가 있습니다. 회사마다 어느 정도의 얼마만큼에 자동화를 하냐가 달라지기 때문에 CI/CD 라고 해서 모두가 똑같은 프로세스를 거치는 것은 아니고, 회사마다 팀마다 다른 방식으로 적용해서 사용할 수 있습니다.

CI 와 CD 가 완벽히 분리된 것이 아니라 대부분의 회사에서 CI 와 CD 를 거쳐서 배포를 진행하기에 CI / CD 라고 묶어서 부르곤 합니다.

 

 

요약해서

CI/CD 의 파이프라인에 대해 간략히 다시 말씀드리면,

개발자가 작은 단위로 나누어서 주기적으로 main 레포지토리에 merge 를 하면, 자동으로 build 를 하고, test 과정을 거쳐서 Release 준비를 하고, 여기서 수동 또는 자동으로 최종 배포를 거치게 됩니다.