팀 프로젝트에서 다른 백엔드 개발 팀원과 동일한 소스 파일 위에서 서로 다른 코드를 작성하고 있다가 나중에 merge를 할 때마다 빈번하게 merge 충돌이 일어났습니다. 또한 통합 이후에 빌드와 테스트 과정을 진행해야 했기에 번거로웠습니다. 결국 CI/CD 구축을 통해 위와 같은 문제점과 번거로움을 해결했습니다. 이 글에서 CI/CD의 개념과 해당 툴에 대해 다뤄보고자 합니다.
CI/CD란?
애플리케이션 개발 단계부터 배포 때까지 이 모든 단계들을 자동화를 통해서 조금 더 효율적이고 빠르게 사용자에게 빈번이 배포할 수 있도록 만드는 것을 말한다.
CI
- Continuous Integration 지속적인 통합의 약자
- 버그 수정이나 새로 만드는 기능들이 메인 리포지토리에 주기적으로 빌드/테스트 되어서 머지되는 것을 말한다.
CI의 2가지 포인트
- 코드 변경사항을 주기적으로 빈번하게 머지해야 한다.
프로젝트에 2명 이상의 개발자들이 협업을 하면서 같이 개발을 하고 있다면, 개발자들이 오랜기간 코드를 변경을 하다가 나중에 merge 하게 되면 충돌되는 많은 코드들이 생겨날 것이다.
이렇게 되면 충돌하는 많은 코드들을 수정하는 데에 시간이 더 오래 걸릴 수 있다. 그렇기에 가능한 작은 단위로 나누어서 주기적으로 빈번하게 개발하고 계속해서 통합하여 나가는 것이 중요하다.
- 통합을 위한 단계(빌드,테스트,머지)의 자동화
Build하고 Test하는 과정은 너무 귀찮다!
빈번하게 통합해줄 때마다 진행해야 하는 과정이기 때문에 귀찮을 뿐 아니라 시간 소모도 있을 것이다. github에 코드만 올리고 나머지 작업인 테스트와 빌드는 프로그램이 자동적으로 해주는 것이다.
CI의 장점
- 주기적으로 merge를 하므로 merge 충돌을 피할 수 있어서 개발 생산성을 향상시킬 수 있다.
- 코드의 검증에 들어가는 시간이 줄어든다.
- 항상 테스트 코드를 통과한 코드만이 레포지토리에 올라가기 때문에 좋은 코드 퀄리티를 유지할 수 있다.
CD
Continuous Delivery 지속적인 제공이라는 의미와 Continuous Deployment 지속적인 배포라는 의미가 있다.
CI에서 Build되고 Test된 후에 배포 단계에서 release할 준비 단계를 거치고 문제가 없는지 수정할만한 것들이 없는지 개발자나 검증하는 팀이 검증을 한다.
그 후에 나온 결론이 "이제 사용자들에게 서비스를 제공해도 되겠다!"라고 정해져서 배포를 수동적으로 진행하는 것이 "Continuous Delivery: 지속적인 제공"이다.
또한 위와 같이 배포할 준비가 되자마자 자동화를 통해 배포를 진행하는 것을 "Continuous Deployment, 지속적인 배포"이다.
CI/CD는 어느 정도의 자동화를 하느냐에 따라 조금씩 다르기 때문에 CI/CD라고 해서 모두 같은 것이 아니라 회사마다 혹은 팀마다 어느정도 차이가 있다.
CD의 장점
- 개발자는 배포보다는 개발에 더욱 신경 쓸 수 있다.
Polling vs Webhook
깃허브에 코드가 업데이트 되었는지는 어떻게 알 수 있을까?
1. Polling : 깃허브에 이벤트가 발생했는지 주기적으로 요청을 보내는 방식으로 상태를 계속해서 확인하는 방식 -> 계속해서 요청을 보내므로 서버에 부담.
2. Webhook : 특정 이벤트가 발생했을 때 타 서비스 혹은 응용프로그램으로 알람을 보내는 기능. 즉, 깃허브에서 코드가 업데이트가 되었다면 CI/CD를 담당하는 Jenkins서버에 요청을 내고, Jenkins서버는 깃허브에서 코드를 가져와 빌드후 배포하게 된다. 또한 에러발생, 빌드실패 등 여러가지 이벤트 상황에서 슬랙에 알람을 보내는 행위도 가능하다.
참고
