CI/CD

CI/CD는 소프트웨어를 개발하는 단계를 자동화함으로서 보다 짧은 주기로 고객에게 제공하는 방법이다.

CI/CD는 지속적 통합, 지속적 제공, 지속적 배포를 말하며,
새로운 코드들의 통합으로 인해 발생하는 문제를 해결하기 위한 솔루션이다 !

주로 애자일 방식을 도입한 개발 및 운영 환경에서 지속적인 통합과 지속적인 모니터링을 제공하게 된다!

지속적인 통합

🛠 개발자를 위한 자동화 프로세스

다수의 개발자가 형상관리 툴을 공유하면서 개발하는 환경에서는 개발자마다 개발 환경도 다를 수 있고, 코드 변경 시 병합되는 과정이 굉장히 까다롭다.

이를 해결하기 위해 빌드 및 테스트 과정을 자동화하고 공유 레포지토리에 통합한다. 이것이 바로 지속적인 통합의 의미이다. CI/CD 파이프라인 빌드를 위한 가장 첫단계 이기도 한다.

애플리케이션의 변경사항이 병합되면 애플리케이션이 손상되지 않도록 자동으로 애플리케이션을 구축하고, 자동화된 방식을 따라 테스트가 진행된다. 테스트가 안정적으로 완료되면 변경사항이 잘 적용되었는지 확인한다.

자동화된 테스트에서 신규 코드 간의 충돌이 발생했다는 것을 파악하여 버그를 더욱 빠르게 수정할 수 있게 된다.

🗝 그래서 ???

지속적인 통합 방식을 적용하게 되면 다수의 개발자들에 의한 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 리포지토리에 통합되어 코드의 충돌을 방지할 수 있다 !!

지속적인 제공

📥 배포 자동화를 위한 준비

CI를 지나고 나면 빌드 자동화, 유닛 및 통합 테스트 수행을 하게 되고 지속적인 제공의 단계에서 이 변경된 코드를 레포지토리에 자동으로 릴리즈하게 된다.

📌 CI가 먼저 필요한 이유 ?
지속적인 제공은 프로덕션 환경으로 배포할 준비가 되어있는 코드를 확보하는 것이 목표이기 때문에 파이프라인에 CI가 먼저 구축되어야 한다.

지속적인 제공은 테스트가 완료되고 변경사항이 적용된 코드를 레포지토리에 자동으로 있게되기 때문에 운영팀이 실시간으로 프로덕션 환경으로 배포할 수 있도록 해준다.

즉, 운영팀이 최소한의 노력으로 아주 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 되는 것이다 !! 😳

지속적인 배포

⚙️ 배포 완전 자동화

지속적인 배포는 지속적 제공의 확장된 형태라고도 볼 수 있는데, 그 이유는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화하기 때문이다.

이전의 과정은 배포하는 과정은 레포지토리에서 테스트가 완료된 코드를 받아 수동으로 해주는 것이었는데 이 방식을 마지막 단계로 도입하게 되면 수동과정이 없게 된다.

많은 것을 자동화하게 되기 때문에 이 단계를 제대로 이루어지도록 하려면 테스트 자동화가 제대로 설계되어 있어야 한다는 것을 꼭 염두해야 한다!! 🥵

마무리

다수의 개발자가 개발을 독립된 기능을 개발하다보면 병합 과정에서 문제가 정말 많이 발생하는데 이 관리 방식을 도입하면 정말 스트레스 받을 일이 많이 사라질 것 같다....🥺

이번에 배포를 공부해보면서 배포하는 과정도 정말 복잡하고 신경 쓸 부분도 많다는 것을 느껴서,, CI/CD를 적용해서 편안함을 겪어보고 싶다!!

참고한 글

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

🖼 이미지 출처
출처