CD/CD
CI/CD는 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Deployment) 또는 지속적 전달(Continuous Delivery)을 의미하며, 소프트웨어 개발 및 배포 프로세스를 자동화하여 코드 품질을 유지하고 더 빠르게 배포할 수 있도록 도와주는 핵심 개념입니다. 실무에서 CI/CD는 보통 버전 관리 시스템(GitHub, GitLab 등)과 연계하여 사용됩니다.
1. CI(Continuous Integration)
- 정의: 개발자들이 각자 작업한 코드를 주기적으로 중앙 저장소에 병합하는 과정. 이때 코드를 병합할 때마다 자동으로 테스트와 빌드가 실행됩니다.
- 목표: 코드가 항상 최신 상태로 유지되고, 각자 개발한 코드가 제대로 동작하는지를 지속적으로 확인할 수 있도록 합니다.
- 실무 적용:
- 코드 푸시 시 자동 테스트 실행: 개발자가 코드를 푸시하면, CI 시스템(GitHub Actions, Jenkins 등)이 자동으로 단위 테스트, 통합 테스트를 실행하여 코드가 제대로 동작하는지 확인합니다.
- 자동 빌드: 코드가 테스트를 통과하면 자동으로 빌드됩니다. 예를 들어, React 애플리케이션의 경우, 빌드가 완료되어 최적화된 정적 파일로 컴파일됩니다.
- 코드 리뷰: 팀원들이 코드를 병합하기 전에 자동으로 테스트가 실행되기 때문에, 리뷰어는 코드 품질에만 집중할 수 있고, 실수를 줄일 수 있습니다.
2. CD(Continuous Delivery)
- 정의: CI를 통해 통합된 코드가 배포 준비 상태가 되는 단계입니다. CI가 끝나고 빌드된 코드가 스테이징 환경에 자동으로 배포되어 추가 테스트를 거칠 수 있습니다. 이때 실제 배포는 수동으로 이루어집니다.
- 실무 적용:
- 스테이징 배포: CI 파이프라인이 완료되면, 코드를 스테이징 서버에 자동으로 배포합니다. 이를 통해 개발자들은 실제 사용자 환경과 비슷한 환경에서 추가 테스트를 수행할 수 있습니다.
- 수동 배포 준비: 스테이징 환경에서 최종 테스트를 통과하면, 운영 환경으로 배포할 준비가 됩니다. 이 단계에서는 자동 배포 대신, 수동으로 관리자가 배포를 승인하는 경우가 많습니다.
3. CD(Continuous Deployment)
- 정의: CI와 CD가 자동으로 끝까지 연결된 방식으로, 모든 테스트를 통과하면 코드가 자동으로 운영 환경에 배포됩니다.
- 목표: 코드를 프로덕션 환경에 최대한 빠르고 안전하게 배포할 수 있도록 하는 것입니다.
- 실무 적용:
- 자동 운영 배포: 코드가 스테이징 환경에서 테스트를 통과하면, 운영 서버에 자동으로 배포됩니다. 이를 통해 사용자에게 빠르게 기능을 배포할 수 있고, 배포 주기를 단축할 수 있습니다.
- 모니터링: 운영 환경에 배포된 후에도 모니터링 도구를 사용해 오류나 성능 문제를 감시합니다. 만약 문제가 발생하면 롤백(이전 버전으로 되돌리기) 기능도 함께 설정해 두는 것이 일반적입니다.
4. GitHub Actions를 이용한 CI/CD 실무 예시
- GitHub Actions 설정: .github/workflows/ 디렉토리 안에 YAML 파일을 작성하여 워크플로우를 정의합니다. 예를 들어, 코드를 푸시할 때마다 자동으로 빌드하고 테스트를 실행하는 워크플로우를 설정할 수 있습니다.
- 예시 워크플로우:
name: CI Pipeline
on:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v2
with:
node-version: '16'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm run test
- name: Build application
run: npm run build
- 실무 적용 흐름:
- 코드 푸시: 개발자가 main 브랜치에 코드를 푸시하면 이 워크플로우가 실행됩니다.
- 테스트 실행: 코드를 푸시할 때마다 자동으로 모든 테스트가 실행되어 코드가 제대로 동작하는지 확인합니다.
- 빌드: 테스트가 통과되면 애플리케이션을 빌드하여 배포 가능한 상태로 만듭니다.
- 배포: 빌드가 완료되면 스테이징 서버 또는 프로덕션 서버에 배포할 수 있습니다.
5. CI/CD 파이프라인의 장점
- 자동화: 반복적이고 시간 소모적인 작업을 자동화함으로써 개발자들이 코드 작성에 집중할 수 있습니다.
- 빠른 피드백 루프: 테스트와 빌드를 자동화하여 문제가 발생할 경우 빠르게 피드백을 받을 수 있습니다.
- 배포 주기 단축: 코드를 빠르게 통합하고 배포할 수 있어 제품 개선 속도를 높일 수 있습니다.
- 안정성: 자동화된 테스트와 배포를 통해 버그나 성능 문제를 미리 발견할 수 있어 운영 환경에서 발생할 수 있는 위험을 줄일 수 있습니다.
6. 실무에서의 사용 예시
- 스타트업에서의 활용: CI/CD를 통해 새로운 기능을 빠르게 개발하고 자동 배포함으로써 출시 주기를 단축하고, 지속적으로 제품을 개선하는 것이 중요합니다.
- 대기업에서의 활용: 복잡한 시스템에서도 CI/CD는 각 기능이 안정적으로 통합되고 배포되도록 해주며, 여러 팀이 협력하는 환경에서 큰 이점을 제공합니다.
Jenkins
Jenkins는 오픈 소스 자동화 서버로, CI/CD 파이프라인을 설정하고 관리하는 데 사용됩니다.
Jenkins는 여러 플러그인을 지원하며, 다양한 작업을 자동화할 수 있어서 DevOps와 CI/CD를 실현하는 데 매우 유용한 도구입니다.
1. Jenkins의 주요 특징
- 자동화: Jenkins는 개발자가 코드를 변경할 때마다 자동으로 빌드, 테스트, 배포 작업을 실행할 수 있습니다.
- 플러그인 시스템: 1,800개 이상의 플러그인을 지원하며, 다양한 작업과 연동할 수 있습니다. Git, Docker, Kubernetes, AWS, GitHub Actions 등 여러 툴과 통합할 수 있습니다.
- 유연성: Java로 작성되었으며, 다양한 운영 체제(Windows, macOS, Linux)에서 실행 가능합니다. 또한, 클라우드와 온프레미스 모두에서 사용할 수 있습니다.
- 자동화 서버: Jenkins는 CI 서버로만 사용되는 것이 아니라, 스크립트 실행, 코드 품질 분석, 배포 트리거 등 광범위한 자동화 작업을 설정할 수 있는 서버입니다.
2. Jenkins의 핵심 개념
- Job(작업): Jenkins에서 실행하는 각각의 빌드, 테스트, 배포 작업을 의미합니다. 여러 종류의 작업을 정의할 수 있으며, 작업이 완료되면 결과를 보고합니다.
- Pipeline(파이프라인): 여러 단계의 작업을 정의하고 실행하는 것을 의미합니다. 일반적으로 파이프라인은 코드가 변경될 때마다 빌드, 테스트, 배포 과정을 자동화하여 처리합니다.
- Master-Slave Architecture(마스터-슬레이브 아키텍처): Jenkins는 마스터와 슬레이브 시스템을 통해 빌드 작업을 분산 처리할 수 있습니다. 마스터 서버는 작업을 관리하고, 슬레이브 서버는 실제 빌드 작업을 실행합니다.
- Jenkinsfile: Jenkins에서 파이프라인을 코드로 정의한 파일입니다. 이 파일을 통해 빌드, 테스트, 배포 과정을 코드로 관리할 수 있으며, 버전 관리 시스템(Git 등)과 연동 가능합니다.
3. Jenkins의 일반적인 사용 흐름
- 코드 변경 푸시: 개발자가 새로운 코드를 GitHub, GitLab 등 코드 저장소에 푸시하면 Jenkins가 이를 감지합니다.
- 자동 빌드 및 테스트: Jenkins는 해당 코드를 자동으로 빌드하고, 단위 테스트, 통합 테스트를 실행합니다.
- 테스트 결과 확인: Jenkins는 테스트 결과를 리포트로 보여주고, 문제가 발생한 경우 알림을 보내줍니다.
- 배포: 코드가 테스트를 통과하면 Jenkins가 스테이징 또는 프로덕션 환경에 자동으로 배포할 수 있습니다.
- 모니터링 및 피드백: Jenkins는 작업 실행 결과를 기록하고, 실패한 작업에 대해 이메일 또는 다른 알림 도구를 통해 경고를 보냅니다.
4. Jenkinsfile 예시
Jenkinsfile은 파이프라인을 정의하는 파일입니다.
예를 들어, Git에서 코드를 가져와 빌드하고, 테스트한 후 배포하는 간단한 파이프라인을 아래와 같이 정의할 수 있습니다:
pipeline {
agent any
stages {
stage('Checkout') {
steps {
// Git에서 코드 체크아웃_
git 'https://github.com/your-repo.git'
}
}
stage('Build') {
steps {
// 빌드 명령 실행_
sh 'npm install'
sh 'npm run build'
}
}
stage('Test') {
steps {
// 테스트 명령 실행_
sh 'npm test'
}
}
stage('Deploy') {
steps {
// 배포 명령 실행_
sh 'npm run deploy'
}
}
}
}
5. Jenkins와 GitHub Actions 비교
- Jenkins: 매우 유연하고 커스터마이징이 가능하며, 큰 조직에서 사용하기 적합합니다. 많은 플러그인과 기능을 제공해 복잡한 CI/CD 파이프라인을 구축할 수 있습니다.
- GitHub Actions: 깃허브와 밀접하게 통합되어 있고 설정이 간단하며, 소규모 프로젝트나 깃허브 중심의 워크플로우를 위한 좋은 선택입니다. Jenkins보다 설정과 사용이 더 간단하지만, Jenkins만큼 복잡한 파이프라인을 다루기에는 한계가 있을 수 있습니다.
6. 실무에서 Jenkins 사용 예시
- 대규모 프로젝트: 여러 개발자들이 동시에 작업할 때 Jenkins는 각자의 코드 변경 사항을 자동으로 통합하고, 테스트하여 코드 품질을 유지합니다.
- 마이크로서비스: 각 서비스의 빌드, 테스트, 배포를 개별적으로 설정하여 관리할 수 있습니다. Jenkins를 통해 여러 마이크로서비스의 CI/CD를 관리하는 것이 가능합니다.
- DevOps 파이프라인: Jenkins는 코드 작성부터 배포까지 모든 과정을 자동화하여 DevOps 프로세스를 완성할 수 있는 중요한 도구로 사용됩니다.
Jenkins는 복잡한 CI/CD 파이프라인을 구축할 때 매우 유용하며, 기업에서 다양한 프로젝트를 관리하는 데 핵심적인 역할을 합니다.
'TIL' 카테고리의 다른 글
[241030 TIL] 가장짧은문자거리(시간복잡도) (0) | 2024.10.30 |
---|---|
[241024 TIL] Docker 개념정리 (1) | 2024.10.24 |
[241017 TIL] CORS 정리 (0) | 2024.10.17 |
[241017 TIL] 디바운싱,쓰로틀링 Closure + HOC로 만들어보기 (0) | 2024.10.17 |
[241016 TIL] stateful/less, OOP vs FP.. 등(GPT 질의) (4) | 2024.10.16 |