CI / CD

개요

팀 프로젝트를 하면서 애플리케이션 자동 배포 및 여러 이점으로 CI/CD를 도입해 사용했고 편리했던 경험이 있었다.

CI/CD를 직접 설정해보지 않았기 때문에 CI/CD에 대해 공부하고 프로젝트에 사용했던 설정을 분석하여 다른 프로젝트에서 적용할 수 있도록 연습해 볼 생각이다.

 

CI/CD 란?

 

CI/CD는 약어로, 몇 가지의 다른 의미를 가지고 있다.

 

CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.

CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

 

CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

CI(Continuous Integration)

• 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 DevOps 소프트웨어 개발 방식
• 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하기 위함
• 지속적 통합은 그 자체로 유익하지만 CI/CD 파이프라인을 구현하기 위한 첫 번째 단계

CD(Continuous Deployment, Continuous Delivery)

• 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것
• 개발자를 위한 자동화 프로세스
• 수동 개입 없이 해당 변경 사항이 프로덕션에  자동으로 배포
• 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포

 

CI/CD의 단계

 

CI(Continuous Integration) - 지속적 통합

• 코드 커밋: 개발자가 코드를 변경하여 버전 관리 시스템에 병합한다.
• 자동 빌드: 커밋된 코드가 자동으로 빌드된다.
• 자동화된 테스트: 빌드된 코드에 대해 자동화된 테스트가 수행된다.
• 코드 품질 검사: 코드 스타일, 린트, 정적 분석 도구를 사용하여 코드 품질을 검사한다.

CD(Continuous Deployment) - 지속적 전달

• 패키징: 빌드된 애플리케이션을 패키징한다.
• 스테이징 환경 배포: 패키징된 애플리케이션을 스테이징 환경에 배포한다.
• 자동화된 수동 테스트: 스테이징 환경에서 추가적인 수동 테스트를 수행한다.
• 릴리스 준비: 코드가 프로덕션 배포를 위한 준비 상태가 된다.

CD(Continuous Delivery) - 지속적 배포

• 프로덕션 배포: 패키징된 애플리케이션을 프로덕션 환경에 자동으로 배포한다.
• 모니터링 및 피드백: 프로덕션 환경에서 애플리케이션을 모니터링하고 사용자 피드백을 수집한다.

 

CI/CD 파이프라인

CI/CD 파이프라인은 코드 커밋에서 프로덕션 배포에 이르기까지의 일련의 자동화된 단계를 의미한다.

1. 코드 커밋 및 버전 관리
   
   • Git 등의 버전 관리 시스템을 사용하여 코드 변경을 추적하고 관리한다.
2. 빌드 단계
   
   • 코드 컴파일, 의존성 설치, 패키징 등의 작업이 포함된다.
3. 테스트 단계
   • 단위 테스트, 통합 테스트, 시스템 테스트, UI 테스트 등 자동화된 테스트를 수행한다.
4. 배포 준비 단계
   • 배포 가능한 아티팩트를 생성하고, 이를 배포 준비 상태로 만든다.
5. 배포 단계
   • 스테이징 및 프로덕션 환경에 애플리케이션을 배포한다.
6. 모니터링 및 피드백 단계
   • 배포된 애플리케이션을 모니터링하고, 성능 및 오류를 추적한다.
   • 사용자 피드백을 수집하여 개선에 반영한다.

 

CI/CD 장단점

장점

1. 빠른 피드백 제공
   
   • 자동화된 테스트와 빌드를 통해 문제를 조기에 발견하고 수정할 수 있다.
2. 높은 코드 품질
   • 지속적인 테스트와 코드 리뷰로 코드 품질이 향상된다.
3. 신속한 배포
   • 배포 주기가 짧아지고, 새로운 기능이 빠르게 사용자에게 전달된다.
4. 효율적인 협업
   • 개발팀 간의 협업이 원활해지고, 코드 통합이 간소화된다.
5. 높은 안정성
   • 자동화된 프로세스로 인적 오류가 감소하고, 안정적인 배포가 가능하다.

단점

1. 초기 설정 비용
   
   • CI/CD 파이프라인을 구축하고 설정하는 데 초기 비용과 시간이 필요하다.
2. 복잡성 증가
   • 파이프라인이 복잡해질 수 있으며, 이를 관리하고 유지하는 데 추가적인 노력이 필요하다.
3. 자동화 도구의 학습 곡선
   • 새로운 도구와 기술을 학습해야 하며, 팀의 적응 시간이 필요하다.

 

CI/CD 적용 방법

1. 도구 선택
   • Jenkins, GitHub Actions, GitLab CI, CircleCI, Travis CI 등 CI/CD 도구를 선택한다.
2. 버전 관리 시스템 사용
   • Git과 같은 버전 관리 시스템을 도입하여 코드 변경을 추적한다.
3. 자동화된 테스트 작성
   • 단위 테스트, 통합 테스트, 시스템 테스트 등 자동화된 테스트 스크립트를 작성한다.
4. 빌드 및 배포 스크립트 작성
   • 애플리케이션 빌드 및 배포를 자동화하는 스크립트를 작성한다
5. 파이프라인 설정
   • 선택한 CI/CD 도구에서 빌드, 테스트, 배포 파이프라인을 설정한다.
6. 모니터링 및 피드백 루프 구축
   • 배포된 애플리케이션을 모니터링하고, 사용자 피드백을 수집하여 개선한다.
7. 지속적인 개선
   • 파이프라인과 프로세스를 지속적으로 모니터링하고 개선한다.

 

CI/CD 도구

GitHub Actions

• GitHub Actions는 GitHub 저장소에 내장된 자동화 도구
• 이슈 응답, 풀 리퀘스트 처리, 라벨 관리 등 다양한 GitHub 이벤트에 반응하여 자동화된 작업을 실행
• .github/workflows 디렉토리에 YAML 파일 형식으로 워크플로우를 정의하여, 특정 이벤트가 발생했을 때 필요한 작업들을 실행
• GitHub 저장소를 사용하는 개발자에게 매우 편리

Jenkins

• 오픈 소스 자동화 서버
• 1000개 이상의 플러그인을 지원하여 거의 모든 종류의 CI/CD 시나리오를 처리 가능
• Groovy 기반의 Jenkinsfile을 작성하여 프로젝트의 빌드, 테스트, 배포 등의 과정을 자동화
• 구성이 다소 복잡할 수 있지만, 그만큼 강력한 커스터마이징이 가능

Team City

• JetBrains에서 개발한 사용 CI/CD 서버
• 도구는 소프트웨어 개발 팀이 더 빠르고 효율적으로 작업을 수행할 수 있도록 설계
• 사용자 친화적인 인터페이스와 강력한 기능이 특징으로, 구성이 쉽고 관리가 용이
• TeamCity는 사전 구성된 기능들이 풍부하여 설정 시간을 최소화하며, 빌드 구성, 테스트 결과 분석, VCS 통합 등 다양한 기능을 제공
• 더 많은 기능과 사용자 지원을 위해서는 유료 라이선스 구매 필요

GitLab

• GitLab은 전체 DevOps 수명 주기를 관리할 수 있는 플랫폼
• 소스 코드 관리(SCM)와 CI/CD를 한 플랫폼에서 제공하여 개발 프로세스를 간소화하고 팀간의 협업을 촉진
• 저장소에 직접 통합되어 있어 별도의 서비스를 구축할 필요 없이 강력한 자동화 기능을 제공
• YMAL 파일을 사용하여 파이프라인을 정의하고, 테스트, 빌드, 배포 등 다양한 단계를 자동으로 처리
• 오픈 소스와 상업용 버전을 모두 제공

 

기술적 의사 결정

팀 프로젝트 회의에서 결정한 내용을 아래에 기록한다.

 

CICD 도구 : Github Actions vs Jenkins

결정 이유

• CI/CD 구축을 위한 시간이 부족하고 빠른 pipeline 구축이 필요함
• 프로젝트 저장소로 Github를 사용함
• 하나의 서버를 사용하는 소규모 프로젝트

결정

• 배울 것이 많은 Jenkins 보다 Github Actions를 선택

AWS vs Naver Cloud Platform

결정 이유

• NCP는 프로젝트에서 많이 사용하지 않아서 익숙하지 않음
• 자료 찾기가 AWS에 비해 어려움
• NCP 크레딧 차감 속도가 빨랐음

결정

• 익숙한 AWS를 서버로 선택

Elastic Beanstalk vs EC2

결정 이유

• Elastic Beanstalk의 경우 자동화를 통해 더 간편하게 처리할 수 있다는 장점이 있지만 세부적인 사용자 정의 설정이 불가능함
• EC2의 경우 서버 내에서 사용자의 제어가 자유롭고 확장이 가능함

결정

• 추후 확장성을 고려해서 EC2를 선택

ECR 사용 vs Docker 단독 사용

결정 이유

• ECR은 docker의 container 관리를 편리하게 해주는 Registry로 버저닝에 효과적
• 프로젝트의 주제가 게임이고 자주 수정이 필요하기 때문에 버전 관리가 필요함

결정

• ECR을 사용해 관리하기로 결정

Nginx - Docker 관리 vs 서버 Install

결정 이유

• Nginx의 경우 MySQL, Redis와 달리 애플리케이션과 독립적임
• 애플리케이션과 서버를 분리하여 관리하면 docker 다운 시에도 서버 유지 가능
• 보안리스크 분산 효과

결정

• Nginx는 EC2 서버에 직접 설치하여 사용

통신 프로토콜 - Https vs Http

결정 이유

• HTTPS는 HTTP에 SSL/TLS 보안 프로토콜을 추가해 데이터를 암호화함
• 데이터 보안 및 무결성을 보장
• SEO에서 더 높은 평가를 받을 수 있다

결정

• HTTPS 사용

 

분량 상 서버 배포에 사용한 docker 파일 분석은 다른 일지에서 후술함