티스토리 뷰

좌충우돌 프로젝트 이야기

CI/CD 파이프라인 구축(1) [Spring Boot, Jenkins, Naver Cloud] - CI/CD의 개념

호춘쿠키 2023. 6. 17. 12:22

CI/CD란 무엇인가?

Wiki는 CI/CD를 다음과 같이 정의하고 있습니다.

 

소프트웨어 공학에서 CI/CD는 지속적 통합(continuous integration)과 지속적 배포(continuous delivery)가 결합한 사례를 의미한다. CI/CD는 소프트웨어의 개발, 테스트와 배포를 모두 통합함으로써 소프트웨어 버그를 쉽게 찾아낼 수 있으며, 더 빠른 배포 주기를 가질 수 있게 만들어 준다. - wiki

 

CI/CD의 사전적 정의도 중요하겠지만, 저는 경험과 실습을 통해 CI, CD를 다음과 같이 정의내렸습니다.

 

CI(continous integration)는 다수의 프로그래머가 함께 작업하는 환경에서 지속적이면서 쉽게 코드를 통합할 수 있도록 지원하는 개발 환경을 말합니다. CI 에는 빌드, 테스트, 통합의 과정이 포함됩니다. 예를 들어, 개발자가 구현을 끝낸 기능의 PR을 요청하면, 코드가 잘 빌드되는지 보고, 올바르게 동작하는지 테스트하며 코드에 버그가 있다면 알려줍니다.

 

CD(continous delivery)는 프로그래머 집단에 의해 작성된 소스코드가 고객이 사용하는 프로그램이 되기까지 필요한 일련의 작업을 자동화하는 것을 말합니다. 예를 들어, GitHub의 feature 브랜치가 main 브랜치에 병합(merge)되었을 때, 자동으로 애플리케이션 서버의 코드가 최신화될 수 있도록 할 수 있습니다.

 

그림1. CI/CD 개요 (출처: https://www.hanl.tech/blog/ci-cd-기본개념과-가장-많이-쓰이는-도구-5가지/)

 

가장 많이 사용되는 CI/CD 도구가 알고싶은 분들은 https://www.hanl.tech/blog/ci-cd-기본개념과-가장-많이-쓰이는-도구-5가지을 참고 부탁드립니다.

 

 

 

 

경험담! CI/CD가 필요한 이유

 

저는 반도체 분야의 IT 부서에서 근무를 한 경험이 있습니다. 회사의 개발 환경에는 CI/CD 파이프라인이 구축되지 않았었는데요. 당시에 어떤 불편함을 겪었는지 소개하면서 CI/CD가 필요한 이유에 대해 얘기해보겠습니다.

 

첫 번째, 코드 병합과 배포 주기가 빨라진다.

제가 속했던 팀은 대략 한 달 간격으로 코드 병합을 진행했습니다. 코드 통합의 주기가 길수록 병합충돌(merge conflict)를 해결하는데 소요되는 작업 시간이 길어집니다. 코드를 병합하는 날이면 야근을 해야됐고, 통합 주기가 길어져서 3달 만에 코드를 병합하는 날에는 오전부터 퇴근까지 하루를 몽땅 쏟아 부을 때도 있었습니다. CI 파이프라인을 구축하게되면  통합 주기의 호흡이 짧아지게 됩니다.

 

두 번째, 개발자가 자신의 코드에 자신감을 갖게된다.

코드 병합에 집중하다보면 정작 비즈니스 로직에 집중하지 못하게됩니다. 이는 버그를 일으키는 환경이 될 수 있습니다. 또한 의도와 다르게 충돌 해결(conflict resolve)하여 버그가 발생하는 경우도 있었습니다. 병합 충돌을 해결했다고 할지라도 결과물을 믿을 수가 없었습니다. 설상가상 테스트코드의 부재로 인해 결과물을 더욱 신뢰하기 어려웠습니다. 한 번은 현장의 전 제품에 대해 패치를 진행했다가 이상이 발견되어 롤백한 적도 있었는데, 당시 상황이 매우 심각했었습니다.

 

이런 상황을 극복해보고자 개인 프로젝트에 CI 파이프라인을 구축해봤습니다. 통합 주기를 짧게 하고, CI 파이프라인에 테스트 코드 정상 실행 여부, 테스트 커버리지 OO% 준수 여부 등을 끼워 넣어 앞서 경험한 문제를 해결할 수 있었습니다. 원한다면 소나큐브와 같은 도구를 이용해 코드 스멜, 보안 취약점 등 다양한 지표 기반의 로직을 CI 파이프라인에 끼워넣을 수도 있습니다. CI 파이프라인에서 이상을 감지하면 개발자는 빠르게 개선하여 코드에 반영할 수 있게 되고, 결과적으로 프로젝트의 코드는 신뢰성이 높고 깨끗해집니다.

 

세 번째, 편리하고 빠르게 서비스 환경을 구축할 수 있다.

회사 업무 중 하나로써 새로운 버전이 릴리즈되면 다른 팀(QA팀, 인프라팀 등)이 관리하는 서버에 배포해줘야 했습니다. 라이브러리, 환경변수 등 꽤나 의존성이 많았던 서비스였고, 수작업으로 설치했기 때문에 많은 시간이 들었습니다. QA팀이 관리하는 서버만 대략 30대정도 였기 때문에 최신 릴리즈로 업데이트하는데만 일주일 이상 소요됐습니다.

 

개인 프로젝트에서 CD 파이프라인을 구축한 결과, 배포 작업의 시간을 엄청나게 단축할 수 있었습니다.

 

네 번째, fast-fail 을 통해 고객의 니즈를 빠르게 반영할 수 있다.

제가 개발하던 제품은 3~4달 간격으로 새로운 버전을 릴리즈하였습니다. 어떤 때는 고객이 의도한 바와 다르게 기능이 구현된 적이 있었습니다. 이로 인해서 최신 버전의 설비가 만든 모든 반도체 제품을 버리게 되는 최악의 상황이 발생했습니다. 

 

CI/CD 파이프라인을 구축했다면 코드 병합, 배포에 필요한 일련의 작업들이 자동화되기 때문에 서비스가 고객에게 빠르게 전달됐을 것입니다. 새로운 버전에 대한 고객들의 반응을 훨씬 빠르게 파악 할 수 있었을 것입니다. 결과적으로 고객이 원했던 기능을 더 빠르게 개발할 수 있었을 것입니다.

 

 

 

 

앞으로 실습할 CI/CD 구조

그림2. 실습할 시스템 구조

 

다음 글부터 실습을 통해 아래 조건을 만족하는 CI/CD 파이프라인을 구축해보도록 하겠습니다.

  • CI/CD 파이프라인 구축을 위해 Jenkins, GitHub Webhook을 이용합니다.
  • 테스트 커비리지가 80% 미만인 경우, 빌드가 실패되도록 CI 환경을 구축합니다.
  • Spring Application을 개발하고 Docker Image로 배포하는 CD 환경을 구축합니다.
  • 네이버 클라우드 플랫폼을 이용합니다.

 

참고 자료

 

다른 글을 보고 싶다면

'좌충우돌 프로젝트 이야기' 카테고리의 다른 글

롤문철 닷컴 구현기 2탄: 로그인 기능 구현 (JWT vs Session)  (0) 2023.07.02
CI/CD 파이프라인 구축(2) [Spring Boot, Jenkins, Naver Cloud] - 테스트 커버리지를 강제하는 CI 파이프라인 구축  (1) 2023.06.17
운영 환경과 개발 환경의 application.yml 을 분리하자 (feat. Jasypt)  (0) 2023.05.18
함수형 프로그래밍을 재고 처리 로직에 적용해보기  (0) 2023.05.02
Security Filter 는 @Bean 으로 등록하지 말자  (0) 2023.04.24
댓글