회사에서 CI/CD 도입을 했어야 했던 이유와 고민했던 서비스 툴을 공유드리겠습니다~!
CI/CD를 적용하게 된 이유
우선 CI/CD를 도입하게 된 계기는 반복되는 빌드/배포 작업을 수동으로 하다 보니 휴먼 에러와 귀찮음(?)이 동반되는 문제가 있습니다.
또 다른 문제로는 만약 운영 코드에 문제가 생겼을 때 롤백하는 작업도 수동으로 해줘야 하다 보니 빠르지 못하는 문제와 역시 휴먼 에러가 발생할 수 있는 여지가 있습니다.
고민했던 CI/CD 서비스 툴
우선 고민했던 CI/CD 툴로는 Jenkins, Tarvis Ci, GitActions로 총 3가지가 있었습니다.
제가 찾아보면서 정리했던 각 서비스 툴의 장/단점을 공유드리겠습니다!
Jenkins
장점
- 플러그인이 많아 다양한 커스터마이징이 가능함.
- 사람들이 많이 사용하고 있어서 참고할 문서가 많음.
단점
- 젠킨스 서버를 둬야 함. (비용발생)
- 규모가 작은 서버에서는 리소스 낭비가 있음.
- 플러그인 버전을 관리해줘야 함.
Travis CI
장점
- 참고할 문서가 많다.
- 직접 운영을 할 필요가 없다.
- UI가 직관적이다.
- Github과 궁합이 잘 맞는다.
단점
- 유료 서비스이다. (기본: 69$/month, 일반: 129$/month)
GitActions
장점
- 별다른 설치 없이 사용할 수 있다.
- 셋업 하는데 리소스가 적게듦.
단점
- 다른 cI/cd보다 래퍼런스가 적음
- UI가 없음.
처음에는 위 3개의 CI/CD 서비스 툴 중에 Travis CI가 좀 더 저희 회사 상황과 잘 맞겠다 생각하여 진행을 했습니다.
(배포에 포함된 커밋 확인 가능, 배포자 확인, 직관적인 UI, 특정 버전 재배포, slack 연동, .env 파일 암호화 전달)
하지만 CI/CD 설정이 끝나고 테스트를 해봤는데.. 배포 속도가 너무 느려서 찾아보니 Travis CI 단점 중 배포 속도 느리다는 단점이 있었습니다..ㅜㅜ
배포 속도가 느린 이슈는 너무 커서 방법을 고민하다 Travis CI → GitActions으로 마이그레이션이 좀 쉽고 Travis CI에서 가능한 대부분 기능들도 GitActions에서 가능하다고 하여 GitActions로 변경을 했습니다.
그렇게 Travis CI에서 5분 이상이 걸리던 배포 속도를 GitActions로 변경하여 1분 내외로 배포할 수 있게 되었습니다.