⚡ CI/CD가 무엇일까?
CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이라고 한다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포이며 CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "인테그레이션 헬(integration hell)")을 해결하기 위한 솔루션이라고 볼 수 있다. 뜻을 하나씩 나눠서 생각해보자.
CI는 지속적 통합이라고 하며 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다고 한다. 이는 모든 개발이 끝난 후에 코드 품질을 관리하는 고전적인 방식으로 단점을 최소화 하기 위한 개념이라고도 볼 수 있다고 한다.
즉, CI는 코드의 변경 사항을 주기적으로 빈번하게 Merge하는데 이때 통합을 위한 단계를 자동화 하는 것이다.
개발의 변경 사항을 레포에 자주 Merge함으로써 코드 충돌을 피할 수 있고, Build 후 Test 과정을 통과했을 때 배포에 반영되고, 만약 어느 단계에서 실패할 경우 해당 부분의 문제를 파악을 빠르게 발견할 수 있다는 장점이 있다.
개발의 변경 사항을 레포에 자주 Merge함으로써 코드 충돌을 피할 수 있고, Build 후 Test 과정을 통과했을 때 배포에 반영되고, 만약 어느 단계에서 실패할 경우 해당 부분의 문제를 파악을 빠르게 발견할 수 있다는 장점이 있다.
CD는 지속적인 배포 혹은 지속적인 서비스 제공이라고 하며 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다고 한다 지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되는 것을 뜻한다고 한다.
즉 CD(지속적 제공/배포)는 우선
지속적 제공은 지속적 통합 단계를 거친 코드들이 배포 준비를 한 후 이것이 실제로 문제가 없는지 개발자가 수동으로 검증을 한 후 배포하는 것을 말한다.
지속적인 배포?
지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올릴 수 있으며 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포된다고 한다. 그래서 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다고 한다.
지속적 배포는 배포 준비가 되자마자 자동으로 배포하는 식으로 자동화를 해 두는 것을 말한다.
CI/CD 종류에는 다음과 같은 것들이 있다.
- Jenkins
- CircleCI
- TravisCI
- Github Actions
우리는 CI/CD를 왜 써야하는가 관점에서 생각해볼때 일일히 빌드와 테스트, 배포과정을 개발자가 직접한다는 것은 리소스낭비이고 심한 경우에는 업무의 대부분을 빌드와 테스트, 배포에 투자해야 할 수도 있기에 CI/CD를 이용하여 배포전 프로젝트를 진행하면서 자동화 구축을 해 두는 것이 좋을 것 같다는 생각이 들었다.
참고자료 및 공식문서
https://www.redhat.com/ko/topics/devops/what-is-ci-cd#ci%EC%99%80-cd%EB%B0%8F-%EB%98%90-%EB%8B%A4%EB%A5%B8-cd%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94
https://seosh817.tistory.com/104
https://www.youtube.com/watch?v=6SvUZqbU37E
