[BE] 집고 백엔드가 사용하는 CI CD 툴
Countinuous Integration(지속적 통합) 이란 말 자체는 우리가 깃허브를 협업에서 사용하는 이유와 비슷합니다. 깃허브를 사용하게 되면 여러 팀원의 버전을 통합하여 관리하기 위해 진행 중간중간 동기화를 위한 노력을 하게 됩니다.
우리는 이 동기화를 조금 더 엄격하게, 안전하게 진행하기 위해 CI라는 과정을 추가하는 것인데요. 새로운 '코드'를 통합할 때 기존의 모든 모듈이 제 기능을 그대로 유지하고 있는지 확인합니다.
그래서 저희는 이 검증 과정이 실제로 코드가 통합되는 과정과 가장 가까이에 있으면 좋겠다는 생각을 했습니다. 코드가 관리되고 있는 곳은 Github 이므로, 이와 가장 가까이에서 CI가 일어나려면 Github Actions가 가장 적절한 선택이었던 것 같습니다.
실제로 PR 자체를 검증하고 깃허브에서 CI 결과를 확인할 수 있는 것은 참 편리하고 안전감을 느낄 수 있는 기능이었습니다.
코드 통합에 이어지는 CD 파이프라인 구축에는 Jenkins를 사용하였습니다. Github Action, Travis CI, Circle CI 등등 많은 선택지가 있지만, CD 파이프라인에 Jenkins를 선택한 이유는 다음과 같습니다.
- 다른 파이프라인 툴에 비해서 자료와 문서가 많습니다.
- 개발자가 직접 설정하고 커스텀 할 수 있는 부분이 많습니다.
- 직접 운용하므로 외부 서비스에 의존하지 않게됩니다. (즉, 집사의고민 서비스가 서드파티 서비스에 의존하지 않게 됩니다.)
- 운용에 필요한 리소스를 제외하고는 이용료가 없습니다.
- 또한, Jenkins는 백엔드 팀원들에게 익숙한 groovy 문법으로 작성되어 있으며, 확장성이 뛰어납니다.
실제로 집고팀은 기술 선택당시 Github Actions와 Jenkins를 고민했었는데요, Jenkins가 ui가 편리하게, 제공하는 기능도 많아 기술을 적용하지 않은 초보자도 무리없이 적응하는 경험을 했고 그 덕분에 더욱 선택에 대한 확신이 생긴것 같습니다. 👍🏻
