동아리 활동을 하면서 배포 자동화 환경 구축을 하게 됐다.
React로 구성될 프론트 쪽도 배포 자동화를 구축하고 싶고 Java/SpringBoot로 구성될 백엔드 쪽도 배포 자동화를 구성하고 싶다.
배포 자동화에 대한 개념을 정확히 모르는 상황인데 이참에 공부해보자..

우리가 고려하는 후보는 총 셋이다.

• Jenkins (유력)
• Github Action
• Travis CI

하나씩 천천히 살펴보자..

CI/CD란?

CI/CD는 배포 자동화를 포함하는 개념이다.
포함하는 개념이란 것은 배포 자동화 외에도 여러가지가 있다는 말이다.

CI

영어로는 Continuous Integration이고 한글로는 지속적 통합이라고 한다.
단어를 살펴보면 "코드에 대한 통합을 지속적으로 진행한다"는 뜻이다.

이걸로 무엇을 얻을 수 있을까? 코드의 품질을 유지할 수 있다.

여러가지 예시를 살펴 봤지만 가장 와닿는 예시가 있었다.

햄버거에 빵, 패티, 야채, 소스 등을 모두 넣은 후 모든 재료가 제대로 들어갔는지, 유통기한이 지나지 않았는지 체크하는 것보다,
재료를 하나씩 넣을 때 마다 유통기한 등을 체크하는 것이 더욱 유리하다.

우리는 개발자니까 개발자의 상황으로 다시 돌아와보자.
우리가 햄버거 예시처럼 이상적인 지속적 통합을 이루기 위해서 규칙을 정한다고 생각하자

1. 모든 개발자는 퇴근 전 자신의 코드를 중앙 코드와 통합한다.
2. 중앙 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.
3. 중앙 코드가 제대로 빌드되는지 테스트한다.
4. 결과를 정리하고 버그가 있다면 다음 날 업무 목록에 적는다.

그러니까 매일 퇴근 전 Git에 코드를 병합하고 문제가 없는지 점검까지 해야하는 것이다.

문제점이 있다.
귀찮다. 그리고 코드가 커질 수록 테스트 시간, 빌드 시간이 점점 길어진다.

이러한 작업을 대신해주는 프로그램이 있으면 좋지 않을까?
Git에 코드만 올려놓으면 알아서 테스트와 빌드를 수행하고 결과를 잘 정리해서 개발자에게 자동으로 알려주는 프로그램이 있으면 정말 좋겠다.

그것이 CI 자동화이다.

그러면 위의 규칙이 간소화된다.

1. 모든 개발자는 퇴근 전 자신의 코드를 중앙 코드와 통합한다.
2. 다음 날 출근 시 메일로 발송된 결과 리포트를 확인하고 버그가 있으면 수정한다.

CD

영어로는 Continuous Deploy/Delivery이며 한글로는 지속적 배포이다.
소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하는 개념이다.

CI의 연장선으로 생각하자. 배포 이전에는 항상 테스트와 빌드가 필수이기 때문에 CD를 이루려면 항상 CI가 선행되어야 한다.

CI 프로세스를 성공적으로 마친 버전의 코드들이 테스트 서버와 운영서버에 곧바로 배포 되는 환경을 CD, 지속적 배포라고 한다.

• CI: 빌드 및 테스트 자동화
• CD: 배포 자동화

이렇게 기억하자.

자 이제 CI/CD를 쉽게 구현할 수 있도록 도와주는 솔루션들인 Jenkins, Travis, Github Action을 알아보자

CI/CD 관련 참고 글 - 코딩장이님의 깃허브 블로그

Jenkins

소프트웨어를 개발할 때 CI/CD 서비스를 제공하는 툴이다.
이 녀석을 사용함으로써 여러명이 하나의 프로그램을 개발할 때 버전 충돌을 방지할 수 있다.
위에서 햄버거 예시로 언급한 것 처럼 작은 단위로 빈번히 업로드함으로써 지속적 통합이 가능하도록 한다.

Jenkins 같은 CI 툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적이었다고 한다.
특히 개발자들이 당일 작성한 소스들의 커밋이 모두 끝난 심야에 이런 빌드 타이머가 집중적으로 진행되었는데 이를 nightly-build라고 한다.

Jenkins를 사용하면 Git과 같은 버전 관리 시스템과 연동하여 소스의 커밋을 감지하면 자동적으로 빌드&테스트를 수행할 수 있다.

Benefits of using jenkins

• 프로젝트의 표준 컴파일 환경에서 발생하는 컴파일 오류 검출
• 자동화 테스트 수행
• 정적 코드 분석에 의한 코딩 컨벤션 준수 여부 체크
• 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시
• 결합 테스트 환경에 대한 배포작업

이 외에도 젠킨스는 1500가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며 스크립트를 이용해 손쉽게 본인의 상황에 맞게 필요한 기능을 추가할 수 있다.

각종 배치 작업의 간략화

프로젝트 기간 중에는 개발 작업 외에도 데이터 베이스 셋업, 환경설정, 배포 작업 등도 해야한다.
이러한 작업들을 원래는 CLI로 직접 타이핑 했었지만 젠킨스를 활용하면 웹 인터페이스로 쉽게 할 수 있다고 한다.

빌드 자동화

Gradle, Maven과 같은 빌드 관리 툴과 연동하여 빌드 자동화를 진행할 수 있다.

자동화 테스트

Git과 같은 버전 관리 시스템과 연동하여 코드 변경을 감지하고 자동화 테스트를 수행한다. 개발자가 미처 실시하지 못한 테스트가 있어도 젠킨스가 테스트를 수행해주기 때문에 핵심이 되는 기능이라고 할 수 있다.

빌드 파이프라인 구성

2개 이상의 모듈로 구성되는 아키텍처가 적용된 프로젝트에는 그에 따른 빌드 파이프 라인 구성이 필요하다.
예를 들면, 도메인 -> 서비스 -> UI와 같이 각 레이어들간의 참조 관계에 따라 순차적으로 빌드를 진행해야만 하는 상황이라면 젠킨스에서는 이러한 빌드의 파이프라인을 구성을 간단하게 구성할 수 있으며 스크립트를 통해서 매우 복잡한 제어도 가능하다.

젠킨스 참고 블로그 - Namjun Kim님의 개발자의 기록습관 블로그

우리 프로젝트

이제 좀 감이 잡힌다.

우리의 프로젝트는
React(프론트) -> API Server 로 구성될 예정이다.

React가 배포될 때 마다 모든 요청이 성공적으로 동작하는지 테스트 하기 위해서 API Server 또한 자동화 테스트가 수행되어야 한다.

반대로 API Server가 배포될 경우 React가 잘 동작하는지 테스트 해야할 것이다.

이런 파이프라인을 구성하는데 있어서 젠킨스, action, travis 무엇을 사용하던지는 크게 중요하지 않다.

다만 우리가 얼마나 복잡한 파이프라인을 구성하느냐에 달려있을 것 같다.
그렇게 그렇게 복잡한 파이프를 구성할까는 싶다.
팀원과 회의를 해봐야할 것 같다.