여러분들이 개발자라면 이 말을 꼭 들어봤을 겁니다. CICD
그렇다면 대체 CICD가 무엇이길래 개발자들의 사이에서 계속 언급되는 걸까요?
이번 글에선 그 CI/CD를 한번 알아봅시다.
정의
CI/CD는 애플리케이션 개발 단계부터 배포까지 과정을 자동화하여,빠르고 안전하게 코드의 변경을 배포하기 위한 자동화 파이프라인입니다.
쉽게 말해, 개발자들이 개발에만 집중할 수 있도록 귀찮고 번거로운 일은 자동화로 돌린다는 말입니다.
그럼 이제 CI와 CD를 한번 나누어 각각 살펴봅시다.
CI, 넌 누구냐
CI는 Continuous Integration, 즉 지속적인 통합을 의미합니다.
예를 들어봅시다. 만약 여러분이 다른 사람과 협업을 진행중입니다.
각자 브랜치를 만들어 오랜 시간 동안 따로 개발을 진행한 뒤 한 번에 머지를 한다면 어떤 일이 발생할까요?
바로 코드 충돌이 발생하게 됩니다.
코드 충돌이 많아질수록 이를 해결하는 데 불필요한 시간이 많이 소모됩니다.
이 문제를 어떻게 해결해야 할까요?
자주 커밋하고, 자주 머지하며, 변경 사항을 빠르게 공유하면 됩니다.
하지만 저희 개발자는 그 누구보다 게으릅니다. 위 방식은 개발자에겐 너무나도 귀찮고 힘든 일이었던 것이죠.
이러한 배경에서 CI가 탄생했습니다.
CI. 즉, 지속적인 통합은 새로운 코드들을 지속적으로 개발 브랜치에 통합하며 코드의 충돌을 최대한 줄이는 방식입니다.
개발자는 코드를 작성하고 커밋만 진행한다면, 이후의 빌드, 테스트 과정은 자동으로 진행됩니다.
장점
- 개발 편의성 향상
- 코드 검증에 들어가는 시간 감소
- 항상 빌드, 테스트를 통과한 코드만 통합되기 때문에 코드의 질 향상
CD?
CD는 CI의 다음 과정, 배포를 자동화하는 파이프라인입니다.
CD는 CI와 다르게 2가지 개념으로 볼수 있습니다.
Continuous Deployment, 지속적인 배포
Continuous Deployment는 코드가 배포 가능한 코드라면 자동으로 배포를 진행하는 과정입니다.
물론 배포 전 많은 테스트를 통해 코드의 문제, 질을 판단합니다.
CI에 이어 CD까지 구축이 된다면, 개발자는 말 그대로 개발에만 신경 쓸 수 있는 개발환경이 완성됩니다.
CI/CD 시스템이 잘 구축되어있다면 하루에도 여러 번의 배포가 가능해집니다.
하지만 이러한 지속적인 배포 방식은 CI의 수준이 높아야하기 때문에 규모가 있는 회사가 아니라면 그 정도의 CI는 구축하기 어렵습니다.
Continuous Delivery, 지속적인 제공
Continuous Delivery는 배포 단계에서 "아 이 코드는 배포해도 괜찮겠다"라고 생각이 들면 배포가능한 상태를 자동으로 만들어두고 사용자의 승인을 기다립니다.
즉, 사용자의 승인이 없다면 배포가 불가능한것이죠.
많은 기업들이 이러한 방식을 사용합니다.
이유는 위에서도 말했듯 지속적인 배포 방식은 CI 시스템의 구축이 힘들다는 점 때문입니다.
Continuous Delivery은 여러분들도 흔히 사용하고 있습니다.
바로 github입니다. github에서도 커밋을 올리고 PR을 날리고, 마지막에 사용자가 승인을 하면 머지가 되는데요.
이게 바로 Continuous Delivery입니다.
이번 글에선 CI/CD를 한번 알아봤습니다.
오늘도 긴 글 읽어주셔서 감사합니다.