24시간 365일 운영되는 서비스에서 배포 환경 구축은 필수 과제 중 하나입니다.
여러 개발자의 코드가 실시간으로 병합되고, 테스트가 수행되는 환경, master 브랜치가 푸시되면 배포가 자동으로 이루어지는 환경을 구축하지 않으면 실수할 여지가 너무나 많습니다.
CI & CD 소개
앞의 글에서 스프링 부트 프로젝트를 EC2에 배포했습니다.
스크립트를 개발자가 직접 실행함으로써 발새하는 불편을 경험했습니다.
그래서 CI, CD 환경을 구축하여 이 과정을 개선해야 합니다.
코드 버전 관리를 하는 VCS 시스템(Git, SVN 등)에 PUSH가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정을 CI(Continuous Integration - 지속적 통합)라고 하며, 이 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정을 CD(Continuous Deployment - 지속적인 배포)라고 합니다.
일반적으로 CI만 구축되어 있지는 않고, CD도 함께 구축된 경우가 대부분입니다.
현대의 웹 서비스 개발에서는 하나의 프로젝트를 여러 개발자가 함께 개발을 진행합니다.
그러다 보니 각자가 개발한 코드가 합쳐야 할 때마다 큰 일이었습니다.
그래서 매주 병합일(코드 Merge만 하는 날)을 정하여 이날은 각자가 개발한 코드를 합치는 일만 진행했습니다.
이런 수작업 때문에 생산성이 좋을 수가 없었으며 개발자들은 지속해서 코드가 통합되는 환경(CI)을 구축하게 되었습니다.
개발자 각자가 원격 저장소(깃허브나 깃랩 등)로 푸시가 될 때마다 코드를 병합하고, 테스트 코드와 빌드를 수행하면서 자동으로 코드가 통합되어 더는 수동으로 코드를 통합할 필요가 없어지면서 자연스레 개발자들 역시 개발에만 집중할 수 있게 되었습니다.
CD 역시 마찬가지입니다.
한두 대의 서버에 개발자가 수동으로 배포를 할 수 있지만, 수십 대 수백 대의 서버에 배포를 해야 하거나 긴박하게 당장 배포를 해야 하는 상황이 오면 더는 수동으로 배포할 수가 없습니다.
그래서 이 역시 자동화하게 되었고, 개발자들이 개발에만 집중할 수 있게 되었습니다.
여기서 주의할 점은 단순히 CI 도구를 도입했다고 해서 CI를 하고 있는 것은 아닙니다.
마틴 파울러의 블로그를 참고해 보면 CI에 대해 다음과 같은 4가지 규칙을 이야기합니다.
- 모든 소스 코드가 살아 있고(현재 실행되고) 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
- 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
- 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
- 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것
여기서 특히나 중요한 것은 테스트 자동화입니다.
지속적으로 통합하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 합니다.