프로젝트를 진행하면서 CI/CD 를 통한 자동화 배포 프로세스를 구축하는 경우가 많다.
우테코에서 이번 팀 프로젝트를 진행하면서 우리팀 역시 CI/CD 프로세스를 구축했으나 결론적으로 CI/CD를 제대로 성공시키지 못했다는 생각을 떨쳐버릴수 없었다.
이번 글에서는 필자가 생각하는 CI/CD란 무엇인지, 그리고 어떤 부분이 문제였는지 한번 작성해 보도록 한다.
CI/CD란 무엇인가?
많은 글과 주변 크루들의 이야기를 들어봤을때 CI/CD에 대한 의견이 많이 갈리는것을 볼 수 있었다. redhat에서 작성한 글과 그 외의 여러 글들을 통해 필자가 이해한 CI/CD에 대해 설명해보겠다.
지속적 통합
지속적 통합은 우리가 pr을 날리고 머지하는 행위라고 말하고싶다. 지속적 통합의 목표는 "머지데이"의 문제점을 제거하기 위함에있다. 과거, CI/CD 가 정착화되지 않았을때 "머지데이"는 많은 인력 리소스를 낭비시켰다. 필자의 경우만 하더라도, 학부시절 팀 프로젝트를 진행하면 서로 변경한 소스를 합치는데 있어서 많은 고통이 있었다(부끄럽게도 학부시절에 Git과같은 버전관리 시스템을 전혀 사용하지 않았다).
위 그림을 살펴보면 Build, Test, Merge까지의 과정을 CI라고 말하고있다. 결국 이 프로세스가 의미하는것은 정상적으로 동작하는, 그리고 충돌이 없는 코드의 병합 을 말한다.
Github를 기준으로 말하자면, PR을 올리고 빌드, 테스트를 검증하고 머지하여 특정 브랜치에 코드가 병합하는 과정까지를 의미한다고 볼 수 있다.
지속적 전달
지속적 전달은 솔직히 말하자면 이름이 잘못된것같다. 이 과정의 목적은 즉시 배포 가능한 코드의 확보 라고 말하고싶다.
Github를 예로 들자면, PR들이 특정 브랜치로 Merge됐다면, 그 브랜치의 코드는 언제든 배포 가능한 상태여야 한다는 것을 의미한다.
따라서 필자는 PR이 Merge될때마다 CI와 같이 Build, Test를 진행하여 코드가 정상적으로 동작하는지 확인해야 한다고 생각한다. 이와 관련하여 혹자는 "PR을 올렸을때 이미 Build와 Test를 진행하고 정상인 것을 확인하였는데 뭐하러 또 다시 이를 확인해야 하는가?" 라고 물을지도 모른다. 이에대한 답변은 우테코의 prolog 프로젝트에서 필자가 작성한 글을 인용하여 답변하도록 하겠다.
지속적 배포
이부분은 모두가 동의하는것 같다. 코드를 Merge 했다면, 적절한 서버로 어플리케이션을 자동 배포하는 그 행위를 의미한다. 레드헷에서는 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다. 라고 명시하고 있다.
reference
https://www.redhat.com/ko/topics/devops/what-is-ci-cd
댓글