CI/CD 도입기-1. CI/CD 란 feat. 우리 팀의 브랜치 플로우 소개

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. - redhat, CI/CD란?

 

 

저는 데브코스에서 진행한 팀 프로젝트에서 CI/CD 및 인프라 개발을 맡았습니다. 그때의 경험기를 5부에 걸쳐서 정리하려고 합니다. 1부에서는 CI/CD의 개념과 필요성, 그리고 기술 선택 이유와 함께 팀의 브랜치 플로우 소개를 담으려고 합니다.

 

1. CI / CD란

여러 명이서 개발한 코드를 한꺼번에 통합하는 과정은 까다롭고 오랜 시간이 걸리기도 합니다. 또한 개발 과정이 길어지면 통합의 어려움은 커지고, 오류 발생의 위험이 증가합니다.

 

이를 해결할 수 있는 방법으로 CI/CD는 새로운 코드의 통합으로 인해, 개발 및 운영팀에 발생하는 문제를 해결합니다.

 

CI, Continuous Integration

• 지속적 통합은 작은 단위로 코드를 수시로 빌드 및 테스트하고 레포지토리에 통합하는 과정입니다
• 기존 코드와 새로운 코드 간에 충돌이 발생하면, CI를 통해 버그를 더 빠르고 자주 수정이 가능합니다

 

CD, Continuous Delivery

• 지속적 제공은 통합된 코드를 레포지토리에 자동으로 릴리즈하는 과정입니다
• 프로덕션 환경으로 배포할 준비가 되어있는 코드를 확보하는 것을 목표로 합니다

 

CD, Continuous Deploy

• 지속적 배포는 어플리케이션을 프로덕션으로 릴리즈하는 작업을 자동화합니다
• 개발자가 어플리케이션을 업데이트 한 후 프로덕션 환경에서 어플리케이션을 바로 실행할 수 있어, 사용자의 피드백을 지속적으로 수신하고 통합하는 일이 수월해집니다

 

필요성

여러 분기의 코드를 통합할 때 발생하는 반복적인 수작업에 많은 시간과 노력이 소요됩니다. 기존 코드와 새로운 코드 간에 충돌이 발생해도, 더욱 자주 빠르게 해결할 수 있습니다. CI/CD 자동화를 통해 애플리케이션을 항상 최신 상태로 유지할 수 있으며, 개발자들은 서비스 개발에 더 집중 할 수 있습니다.

 

2. CI / CD 비교 분석 : Jenkins vs Github Action

대표적인 CI/CD 도구에는 Jenkins와 Github Action가 있습니다.

 

Jenkins

• 무료 오픈소스 자동화 서버입니다
• 파이프라인을 사용해 소스코드 레포지토리에 대한 지속적인 통합과 배포를 무료로 제공합니다
• 대시 보드 기능과 다양한 플러그인을 제공합니다

 

Github Action

• Github에서 제공하는 SaaS(Software as a Service) 입니다
• 모든 플랫폼에서의 프로젝트 빌드, 테스트, 배포를 쉽게 자동화 할 수 있습니다
• Github에서 일어나는 이벤트를 기반으로, 워크플로우를 만들어서 자동화하는 도구입니다

 

최종 결정 : Github Action

결정에 있어서 가장 중요하게 생각했던 부분은 “간단함”이였습니다. 우리 프로젝트는 2-3주의 짧은 개발 기간을 가지고 있었고, 프로젝트 목적 상 Spring을 사용하는 백엔드 개발이 중심이 되어야 했기 때문입니다.

 

1. 클라우드에서 동작하므로, 어떤 설치도 필요하지 않다

Jenkins를 사용하기 위해서는 서버를 띄워야 합니다. 하지만 Github Action은 클라우드에서 작동하며, 설정 과정이 훨씬 간단합니다.

 

2. Github 이벤트에 대해 빠른 처리가 가능하다

팀은 Github Action을 사용해 프로젝트를 진행하는데, 이때 발생하는 모든 이벤트를 통해 Github Action을 실행할 수 있습니다.

 

3. Github을 사용해 간단하게 보안 처리가 가능하다

Github와 연결되어 있어 Github 계정으로 권한과 관리 시스템을 사용할 수 있습니다. Jenkins는 직접 보안 취약점을 관리해야 합니다.

 

3. 팀의 깃 브랜치 플로우 소개

팀의 깃 브랜치 플로우는 위와 같습니다. 해당 과정에서 github action이 적용되는 부분에 대해서 소개하려고 합니다.

 

팀의 브랜치는 세 가지 종류로 나뉩니다.

• Main : 주요 브랜치로, 스프린트를 기록하는 브랜치
• Develop : 주요 브랜치로, 릴리즈와 배포가 이루어지는 브랜치
• Feature : 이슈를 단위로 만들어지며, 실제로 개발이 이루어지는 브랜치

 

Feature → (pull request) → Develop

가장 먼저 구현하고자 하는 기능을 이슈 단위로 정리하고, 이를 기준으로 feature 브랜치를 만들어 분업 아래 각자 개발을 진행했습니다. 이후 feature 브랜치의 개발이 종료되면 dev에 pull request를 요청합니다. github action을 통해, 해당 변경 사항에 대해 테스트와 빌드를 진행하며 검증합니다.

 

Feature → (push) → Develop

문제가 없다고 판단된 해당 feature은 dev에 통합됩니다. 이때 dev 브랜치는 push(merge)가 되면, github action을 통해 CI/CD를 진행합니다. 이렇게 하나의 개발이 통합되면 자동으로 빌드와 테스트, 릴리즈, 배포를 진행합니다. 동시에 통합된 feature 브랜치는 삭제됩니다. 짧은 시간 내에 보다 많은 릴리즈와 배포를 경험하기 위해서 dev에서 바로 릴리즈와 배포를 진행하는 플로우를 계획했습니다.

 

4. 마무리

이렇게 CI/CD 도구로 Github Action을 사용한 과정과 깃 브랜치 플로우를 소개하면서 대략적인 적용 흐름도 설명해 보았습니다. 다음 편에는 docker와 docker compose를 중심으로 프로젝트를 어떻게 릴리즈하고 배포했는지에 대해 설명하려고 합니다.

 

5. 레퍼런스

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

https://www.hanbit.co.kr/media/channel/view.html?cms_code=CMS2262224323

https://hoi5088.medium.com/ci-cd-개념-4e6a45dbcfe2

https://wookiist.dev/155