소프트웨어 개발 및 배포 과정에서 중요한 역할을 하는 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인은 팀이 신속하고 안정적으로 코드를 통합하고 배포할 수 있도록 도와준다.
이를 통해 개발 주기를 단축하고 품질을 향상시킬 수 있다.
이번 글에서는 CI와 CD가 무엇인지, 그리고 왜 필요한지에 알아보자.
CI (Continuous Integration, 지속적인 통합)
CI는 소프트웨어 개발에서 팀원들이 개별적으로 작성한 코드를 정기적으로 통합하는 프로세스이다.
이는 git에서 빈번하게 머지하는 것도 포함된다.
CI의 주요 목표는 일관성을 유지하고 통합(머지) 시 발생할 수 있는 문제를 테스트를 통해 신속하게 발견하여 해결하는것이다.
왜 CI가 필요한가?
- 빠른 피드백 제공: CI는 각 통합 시마다 자동으로 빌드와 테스트를 수행하여 코드 변경이 기존 기능에 영향을 미치는지 신속하게 피드백을 제공한다.
- 버그 조기 발견: 코드가 자주 통합되므로 작은 변경 사항에서 발생하는 버그를 즉시 발견하고 수정할 수 있다.
- 개발 효율성 향상: 개발자가 개별적으로 작업한 코드를 자주 병합함으로써 충돌을 최소화하고 협업 효율성을 높인다.
- 품질 보증: 자동화된 테스트를 통해 코드 품질을 지속적으로 유지할 수 있다.
CD (Continuous Delivery, 지속적인 배포)
CD는 CI의 다음 단계로, 프로덕션 환경에 배포하기 위한 준비 과정을 자동화하는 것이다.
Continuous Delivery와 Continuous Deployment라는 두 가지 개념이 있으며, 둘 다 배포 자동화에 초점을 맞추지만 약간의 차이가 있다.
- Continuous Delivery: 코드 변경이 자동으로 빌드, 테스트, 배포 준비가 완료되며, 실제 배포는 수동으로 해야한다.
- Continuous Deployment: 코드 변경이 자동으로 빌드, 테스트, 배포까지 이루어져 개발자 개입 없이 프로덕션 환경에 배포된다.
왜 CD가 필요한가?
- 신속한 배포: 자동화된 배포 프로세스를 통해 소프트웨어를 더 빠르게 릴리스할 수 있다.
- 일관성 있는 배포: 수동 작업에서 발생할 수 있는 실수를 줄이고 일관된 배포를 보장한다.
- 고객 만족도 향상: 새로운 기능과 버그 수정을 더 빠르게 제공함으로써 고객 만족도를 높일 수 있다.
- 지속적인 개선: 배포 주기가 짧아지므로 사용자 피드백을 빠르게 반영하고 소프트웨어를 지속적으로 개선할 수 있다.
CI/CD를 구축하기 전에..
CI/CD 구축이 뚝딱 만들 수 있는 쉬운 것이 아니다.
데브옵스 엔지니어가 따로 존재할만큼 비용을 수반하는 작업이며, 추후에 유지보수를 고려해야할 수 있다.
필자의 경우에는, 코드의 머지가 빈번하지 않고 애플리케이션 기능 개발이 우선시 되어 CI/CD를 구축하기에는 어려움이 있었다.
하지만, 프로젝트의 특성상 빠른 배포를 통해 효율적인 피드백 루프가 필요했고 별도의 CI/CD구축이 필요없는 vercel을 사용하게 되었다.
(vercel의 deployment)
모든 브랜치에 대해 build및 deploy가 자동화 되며 효율적인 피드백 루프를 구축할 수 있었다.
테스트
CI의 목적성을 생각하면, CI의 핵심은 테스트 자동화라고 생각한다.
하지만 vercel에서는 테스트 자동화를 구축하기에 알맞은 설정을 제공하지 않는듯 보였다. 🥲
또한 production과 분리된 개발용 db를 사용한다면 마이그레이션을 자동화 하는것도 고려해보아야 한다.
이러한 이유로 github-action을 사용하여 CI를 새로 구축하게 되었다.
구축하고자 하는 CI/CD 설계는 다음과 같다.
- main 브랜치가 아닌 다른 브랜치(Preview)
- commit 전 husky를 이용하여 로컬 환경에서 테스트를 거친다.
- push 후에는 기존대로 vercel의 Preview 환경으로 빌드 및 배포한다.
main 브랜치(Production)
- push 후에 preview_db의 스키마와 타입 연동이 제대로 되었는지 확인한다.
- 동시에, production_db에 preview_db의 스키마를 마이그레이션한다.
- 1, 2가 성공하면 playwright e2e 테스트를 진행한다.
- vercel에 빌드 아키펙트를 전송한다.
- vercel에서 배포한다.
Preview환경은 빠른 피드백을 받기 위해 github-action을 사용하지 않고 테스트가 더 빠른 로컬 환경에서 테스트를 진행하도록 했다.
(production환경의 github-action 파이프라인)
후기
- 테스트가 자동화 되어 수정된 코드에 대해 안심이 되는 느낌이다 😂
- dev_db와 prod_db가 분리되어 있을 경우에는 마이그레이션 작업도 하나의 일인데, 자동화를 하고 나니 실수할 일도 없고 굉장히 안정적이다.
- CI/CD 파이프라인이 시간이 오래 걸릴 수도 있지만, Preview환경을 따로 분리하여 빠른 배포를 구현하여 효율적인 피드백 루프를 구축할 수 있었다.