근래 들어 Jenkins를 사용하며, 병합과 배포 자동화에 상당한 편리함을 느꼈으며,
이에 대한 정의가 필요할 것이라 여겨져 좋은 설명을 한 개발자분들의 포스팅을 정리.
사실 CI/CD 개념 자체만 두고 보자면 자동화와 직접적으로 관련있는 내용은 아니다.
그럼에도 불구하고 CI/CD하면 거의 항상 따라오는것이 자동화인데,
프로젝트의 크기가 커질수록 자동화가 배제된 CI/CD는 더더욱 상상하기 어려워진다.
이게 도대체 무슨 소리인지, 우선 CI/CD가 무엇인지부터 간략히 살펴보자.
10명의 개발자가 참여하는 프로젝트가 있다고 가정해보자.
git에 기본 틀이 잡혀있는 코드가 올라와있고,
각 개발자가 자신의 로컬환경에 clone 받아서 작업을 시작한다.
그런데 개발이 끝날때까지 모든 개발자가 한 번도 중앙저장소에 코드를 올리지 않았고,
개발이 끝난 이후에 10명의 개발자의 코드를 한 번에 통합해야하는 상황이라면?
그렇다면 지속적 통합을 이루기 위해서는 어떻게 해야할까?
- 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.
- 통합된 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.
- 통합된 코드가 제대로 빌드되는지 테스트한다.
- 결과를 정리하고. 버그가 있다면 다음날 업무 목록에 적어둔다.
매일 퇴근하기 전에 git에 코드를 올리고 문제가 없는지 테스트하라는 것이다.
하지만 CI의 단점은 ‘너무 귀찮다’는 것이다.
이렇게 되면 어떨까?
git에 코드만 올려놓으면 알아서 테스트와 빌드를 수행하고,
그 결과를 잘 정리해 개발자에게 자동으로 알려주는 프로그램이 있다면 좋지 않을까?
그렇기에 CI를 설명할때 항상 자동화라는 키워드가 따라다니는 것이다.
CD가 되려면 CI가 선행되어야 한다.
어려울것 없이 CD는 CI 의 연장선으로 생각하면 된다.
즉, CI 프로세스를 통해 개발중에 지속적으로 빌드와 테스트를 진행하며,
이를 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포에 반영하는 것이다.
테스트와 빌드가 '지속적'으로 이루어 진다면, 배포 또한 '지속적'으로 이루어진다.
CI = 빌드 및 테스트 자동화
CD = 배포 자동화
CI/CD 를 자동화하기 위해서는 고려해야할 부분이 생각보다 많으며,
언제, 어떤 자동화 프로세스를, 어떻게 돌리고,
어떤 방식으로 결과를 리포트할지 등의 절차를 매우 엄밀하게 정의해야한다.
CI/CD 자동화 솔루션 : CircleCI, Travis, Jenkins, ...
참고 블로그
(velog.io/@ash3767/CICD)[https://velog.io/@ash3767/CICD]
(itholic.github.io/qa-cicd/)[https://itholic.github.io/qa-cicd/]
유익한 정보를 얻을 수 있어서 기쁩니다.