지속적 통합 및 지속적 전달(CI/CD) 구축 사례

1. 지속적 통합 및 지속적 전달(CI/CD)이란

여러 명의 개발자가 개발한 소스를 지속적으로 하나로 통합하는 것을 ‘지속적 통합’(Continuous Integration)이라 하고 줄여서 CI라고 합니다. 빌드 결과물을 지속적으로 전달하여 제품의 질적 향상을 꾀하는 것을 ‘지속적 전달’(Continuous Delivery)이라 하고 줄여서 CD라고 합니다. CI/CD를 하는 이유는 다음과 같습니다.

• 코드 통합 시 생기는 문제점을 사전에 발견하여 처리
• 빌드 형상 관리
• 담당자가 아닌 사람도 쉽게 빌드 가능
• 개발자가 개발에만 집중할 수 있도록 하기 위함
• 자주 배포하여 자주 피드백을 얻는 개발 프로세스를 가능하게 함

목차

1. 지속적 통합 및 지속적 전달(CI/CD)이란
2. 구축 사례
   1. CI/CD 흐름도
   2. Jenkins 2.x
   3. Jenkins 구성
   4. 개발 단계
   5. 품질보증 단계
   6. 배포(deployment) 단계
3. 맺음말

2. 구축 사례

2.1. CI/CD 흐름도

당사에서 적용한 CI/CD의 흐름도는 아래와 같습니다.

2.2. Jenkins 2.x

CI/CD를 구축하기 위해 Jenkins 2.x라는 소프트웨어 솔루션을 이용했습니다. 이 소프트웨어는 다음과 같은 특징이 있습니다.

• 무료
• 다양한 플러그인
• 사용 유저가 많아 이슈 해결이 쉬움
• 파이프라인 플러그인(pipeline plugin) 이용, 스크립트 코드를 통한 영속적으로 유지되는 CI를 통해 반복 작업을 최소화

2.3. Jenkins 구성

당사에서는 CI/CD 프로세스를 개발(development), 품질보증(QA), 배포(deployment) 이상 3단계로 구성하고 있습니다.

2.4. 개발 단계

개발 단계는 CI가 수행되는 단계입니다. 이 작업에서는 개발을 위해 Git으로 올라온 코드를 지속적으로 빌드하고 테스트해서 결과를 보고하는 역할을 담당합니다. 작업은 파이프라인을 통해서 구성되었는데, Android와 iOS가 구성되어있으며 범용적으로 사용하는 기능을 ‘functional’이라는 업무(job)로 분리하여 관리하고 있습니다.

예시 프로젝트의 경우 Android와 iOS가 같은 레포지토리에서 작업이 되고있어 커밋을 체크하여 iOS 수정인지 Android 수정인지 구분하여 빌드를 실행해주는 분배기가 필요했습니다. ‘CI BUILD CHECKER’가 그 역할을 수행합니다.

CI BUILD CHECKER 코드 일부

//커밋 메세지를 얻는다. gitLogMessage = “git log –pretty=’format:%H-%ae-%s’ {이전커밋}..{지금커밋}” //iOS 빌드가 실행 gitLogMessage+” –grep=’\\[iOS\\]’ -i” //Android 빌드가 실행 gitLogMessage+” –grep=’\\[Android\\]’ -i” //iOS, Android 둘다 실행 gitLogMessage+” –grep=’\\[Plugin\\]’ -i”

2.4.1. 개발 단계 흐름도

개발 단계의 흐름도는 아래와 같습니다. 현재 실패 시에만 결과를 리포트 하는 구조로 작업이 되어있으나, 추후 이전 빌드가 실패였을 경우 성공에도 리포트를 전달하는 구조로 변경 예정입니다.

2.4.2. 빌드 보고서

Jenkins가 빌드 후 개발자에게 전송한 URI를 통해 리포트에 접근할 수 있습니다.

빌드 로그 보고서

빌드 로그 보고서 화면에서 ‘Console Output’ 메뉴에서 빌드 시 출력된 로그를 확인 가능합니다.

빌드 시 출력된 표준 출력 및 표준 에러 등을 확인 가능합니다.

단위 테스트 보고서

단위 테스트에 대한 보고서를 볼 수 있습니다

코드 커버리지 보고서

테스트에서 코드가 얼마나 테스트 되고 있는지 볼 수 있는보고서입니다.

2.4.3. 빌드 보고서 통지

메신저

당사에서 업무용으로 사용하고 있는 메신저는 웹훅 기능을 지원합니다. 이 기능을 이용해 빌드 실패 시 리포트를 통지합니다.

이메일

Jenkins에서 무언가 통보하고 싶을 때, 메일을 통해 자세한 사항을 전달할 수 있습니다. 긴 로그를 보내도 메일 특성상 읽는데 부담이 없습니다. 다만 과도하게 많은 메일을 수신하게 되면 나중에는 읽지 않게 될 가능성도 있습니다. 채널 구분이 상대적으로 메신저에 비해 어렵다는 단점도 있습니다.

2.5. 품질보증 단계

품질보증 단계는 QA 부서에 빌드를 전달하기 위한 작업입니다. Git에 커밋된 내용을 기반으로 하여 사용자가 커밋 해시(commit hash)와 버전 명을 입력하여 빌드를 전달하게 됩니다.

2.5.1. QA 부서에 제공할 빌드 수행

Git에서 생성한 태그를 이용하여 빌드를 생성합니다.

Git의 개정(revision) 번호와 버전 명, 그리고 빌드할 타겟 플랫폼을 지정하여 빌드를 수행합니다.

빌드가 성공하면 앱 배포 시스템에 업로드 되며, 메신저의 웹훅을 통해 메시지가 전송됩니다.

2.5.2. QA 완료된 빌드를 배포 빌드로 전환

QA가 완료되면 해당빌드를 배포 빌드로 전환시킬 수 있습니다. 여기서 배포 빌드란 실제 배포가 가능한 빌드를 말합니다.

2.6. 배포(deployment) 단계

테스트와 QA가 끝난 빌드를 배포하기 위한 작업이다. FTP 업로드 문서 갱신 등을 담당하게 되며, QA가 완료된 빌드만 배포 작업으로 넘어 올 수 있습니다.

품질보증 단계에서 ‘Promotion Status’를 선택하면 자동으로 배포 단계로 넘어옵니다. 여기서 한번 더 ‘Promotion Status’를 선택하면 배포 작업을 시작하게 됩니다.

3. 맺음말

객체지향 설계원칙에 ‘DRY’라는 말이 있습니다. “Don’t Repeat Yourself”의 약자로 반복하지 말라는 말입니다. 물론 이것은 중복 코드를 배제하고 추상화를 잘하여 실수를 줄이고 유지보수성을 높이자라는 의미에서 사용된 말이지만 배포에서도 똑같이 적용된다고 생각합니다. 왜냐하면 배포의 경우도 배포 담당자가 배포를 위해 매번 다양한 프로세스를 중복적으로 진행하고 어찌보면 이 일이 중복 코드를 매번 작성하는것과 동일하기 때문입니다. 그렇기 때문에 ‘DRY’의 원칙에 따라 반복되는 일을 한가지로 추상화하기 위해 CI/CD 프로젝트를 진행하였고, 결과적으로 “배포 버튼을 누른다”라는 한 가지 인터페이스를 통해 배포를 진행하도록 리팩토링 했다고 볼 수 있습니다.

사소한 일이라도 반복되는 프로세스를 자동화를 하다보면 실수도 줄일 수 있으며 인수인계나 개발 속도 등에서도 많은 이득을 볼 수 있습니다. 이 글이 참고가 되었으면 좋겠습니다. 감사합니다.