어쩌다보니 팀에서 CI/CD 업무를 맡게 되었고, 얼마전에 프로젝트가 끝이 났다(물론 기능 추가를 위해 추후 몇번의 리팩토링을 거치게 되겠지만). 'CI/CD, 제가 한번 맡아서 해보겠습니다'라며 적극적으로 나서서 한 건 아니고 시켜서 한 일이지만, 프로젝트가 끝나고 보니 그 목적에 대해 내가 제대로 모르고 있다는 것을 깨달았다.
누가 '그래서 이거 왜 했어요?' 라고 물어본다면 아, 이 방식으로 빌드, 테스트 및 배포를 진행한다면 코드 퀄리티가 높아집니다..라고는 대강 설명할 수 있겠으나, 그래서 어떻게 코드 퀄리티가 좋아지고, 왜 써야 하는지 물어본다면 대답할 수는 없었다. 뭐 지금까지 했던 것처럼 로컬에서 빌드하고, 빌드가 제대로 되면 수동으로 릴리즈 노트 작성하고, 배포하는 방식을 유지하는게 편한 사람들도 있을 것이다. 하지만 그게 최선의 방식이라면 CI/CD 개념은 생겨나지 않았을 것이다. 오늘 한번 이걸 왜 써야하는지 한번 더 공부해보고, 정리하고자 이렇게 포스팅을 남기게 되었다.
CI/CD
소프트웨어 개발 단계에서 자동화를 통해 고객에게 빈번하게 앱을 배포하는 방법이다.
✅ CI(Continuous Integration) : 지속적인 통합
여러 개발자들이 사용하는 공유된 repository가 하나 있다고 하자. 개발자들은 각자의 브랜치에서 필요한 작업들을 하고, 작업이 완료된 브랜치를 메인 브랜치에 머지한다. 이 과정이 주기적으로, 빈번하게 이루어져야 하며, 머지된 코드는 최종적으로 배포되기 전에 자동화된 환경에서 빌드되고, 테스트되어야 한다. 이 모든 과정이 바로 CI다. 이 방법은 대규모 프로젝트에서 수많은 브랜치들간의 머지 충돌을 피할 수 있는 해결책이다.
예를 들어 2명의 개발자가 동일한 repository에서 작업을 하고 있다고 치자. 각자 광범위한 범위를 수정하다가 수정된 코드를 메인 브랜치에 머지하게 되면 자칫하다 충돌이 발생할 수도 있다. 또한 많은 범위를 수정하게 되어 어느 부분이 충돌을 발생시켰는지 확인하는데에 많은 시간이 소요될 수 있다. 하지만 서로 작은 범위를 맡아 주기적으로 빈번하게 머지하게 된다면 그만큼 머지 충돌도 피할 수 있게 되고, 버그 발생 시 수정해야 할 부분이 작아서 유지보수에도 용이해진다.
따라서 CI를 수행한다면 다음과 같은 장점들을 얻을 수 있다.
- 주기적으로 빈번하게 머지하기 때문에 머지 충돌을 피할 수 있어서 개발 생산성 향상
- 머지된 모든 코드들이 자동으로 빌드되고 테스트되기 때문에 신속하게 버그 발견 가능(버그 수정 용이)
- 이 모든것들을 통해 좀 더 나은 코드 퀄리티를 가질 수 있고, 안정성있는 개발 가능
코드 리뷰 이후, 변경된 코드가 머지된 repository가 팀에서 만든 CI용 스크립트를 통해 자동으로 회사의 CI 서버에서 빌드된다. 어떤 툴(Jenkins, Circle CI, Github actions)을 쓰냐에 따라 다르겠지만 각 회사에서 사용하는 툴에서 빌드 결과를 확인할 수 있다. 또한 빌드 및 테스트 후 자동으로 릴리즈 노트를 올릴 수 있도록 Github에서 API를 제공하고 있다.
한번은 이런 일이 있었다. 새롭게 변경사항이 머지된, 배포 직전의 프로젝트를 CI 서버에서 빌드하고 있었는데, 그 전까지 잘 빌드되다가 갑자기 안되는 것이다. 로컬에서 확인해보니 직전에 메인 브랜치에 자신이 수정한 코드를 머지했던 개발자가 일부 코드를 잘못 작성했던 것이 원인이었다. 만약 CI 서버에서 빌드하고 테스트하지 않았다면 버그를 안고 있는 프로젝트가 그대로 배포되었을 것이다.
✅ CD(Continuous Delivery or Continous Deployment) : 지속적인 제공, 지속적인 배포
이제 모든 테스트가 끝난 프로젝트를 배포할 준비가 되었다. 여기서 이 배포 과정을 수동으로 할 수도 있고, 배포 과정까지 자동화 할 수도 있는데, 개발팀 또는 운영팀에서 수동으로 배포하는 것을 지속적인 제공(Continuous Delivery)으로 표현하며, 배포 과정이 자동화된 것을 지속적인 배포(Continous Deployment)라고 한다.
어떤 방식을 사용하냐는 회사마다 다르다. 개발팀(또는 운영팀)에서 수동으로 검사하고 배포하는 Continous Delivery 방식을 사용할 수도 있고, 배포까지 빠른 속도로 진행하고 싶다면 Continous Deployment 방식을 사용할 수도 있다.
References
https://youtu.be/0Emq5FypiMM
https://www.redhat.com/en/topics/devops/what-is-ci-cd
