CI/CD를 구축해보자.

개요

새로이 코드를 개발하여, 서버에 실제로 배포를 하기 까지에는 기존 코드에 통합, 빌드 테스트, 빌드, 배포 서버에 배포까지 매번 반복적인 작업을 거치게 됩니다.

매번 반복되는 병합/배포 작업을 자동화시키기 위하여 CI/CD 도구를 도입하게 되었습니다.

CI/CD 란?

CI (Continuous Integration) - 지속적인 통합

코드의 변경사항을 기존 코드와 병합하고, 병합한 코드가 올바르게 동작하는 지를 검증하여 배포하는 것

CD (Continuous Delivery) - 지속적인 배포

소프트웨어가 지속적으로 배포되도록 하는 것. 배포 자동화

CI/ CD 도구 비교

도구를 선택하기에 앞서 많이 사용되는 CI/CD 도구 몇가지를 비교해 보았습니다.

Jenkins

Java 기반의 오픈 소스 입니다. 오래된 만큼 문서와 플러그인이 많고. 다양한 세팅을 할 수 있다는 점이 장점이나, 그만큼 초기 세팅에 시간이 걸리고, Jenkins를 설치하여 사용해야 하기 때문에 따로 관리해주어야 한다는 단점이 있습니다.

GitHub Action

GitHub에서 제공하는 CI/CD도구입니다. 설정이 간단하고 YAML 기반 워크 플로우 파일을 작성하여 워크 플로우 파일을 작성하여 손쉽게 작업을 정의할 수 있습니다. 실행환경이 깃허브에서 호스팅되기 때문에, 프라이빗 환경에서는 추가적인 설정이 필요할 수도 있고, 무료 버전은 기능이 제한적이라는 단점이 있습니다.

Travics CI

상용 CI 서비스 툴입니다. 웹으로 서비스가 제공되어 짐으로 별도의 서버를 운영할 필요가 없고. Git Hub, Bit Bucket 등의 레포지토리와의 연동이 쉬운 것이 장점입니다. 상업용은 유료이고, Jenkins에 비해 플러그인이 적다는 것이 단점입니다.

우리의 선택은?

저희는 Jenkins 를 선택하였습니다. 저희 팀원들이 Jenkins 를 사용해본 적이 있어서 익숙하였고, 다양한 플러그인이 있어 상세한 설정이 가능하다는 점이 마음에 들었기 때문입니다.

Jenkins 적용하기

Jenkins를 위한 별도의 서버를 두지 않고, atticket을 배포할 서버에 Jenkins을 설치하였습니다.

다음과 같이 CI/CD 과정을 구축하였습니다.

1. 개발자가 코드를 깃허브에 푸시한다.
2. 깃허브가 webhook을 통해, Jenkins로 요청을 보낸다.
3. Jenkins가 도커를 사용하여 빌드 및 배포를 한다 
    (docker compose를 이용하여 배포 간소화)

코드가 main branch 에 Push 되면 webhook 설정을 통하여 Jenkins가 main branch의 코드를 자동으로 pull 받아오게 됩니다.

저희 프로젝트는 서브 모듈 프로젝트로, 완전한 atticket 프로그램을 띄우기 위해서는 여러 모듈들을 전부 실행시켜주어야 할 필요가 있습니다.

서버에 배포시킬 때도 로컬에서 빌드시킬 때와 마찬가지로 배포시에도 docker compose 파일을 이용하여 배포하게 됩니다.
docker compose 파일에는 배포에 필요한 설정이 적혀져 있습니다.
여러 모듈로 이루어진 프로젝트이기 때문에 자칫 배포에 여러 과정이 필요할 수 있지만, docker compose를 사용하여 배포를 간단히 만들 수 있었습니다.