CI (Continuous Integration, 지속적 통합)
CI는 개발 과정에서 중요한 역할을 한다. 기본적으로, CI는 개발자들이 코드 변경사항을 주기적으로 메인 저장소에 통합하는 프로세스를 의미한다. 이 프로세스의 핵심 목표는 소프트웨어 품질을 향상시키고, 개발 과정에서 발생할 수 있는 복잡성을 줄이는 것이다. CI의 주요 특징은 다음과 같다:
-
자동화된 빌드와 테스트: 개발자가 소스 코드를 공유 저장소에 푸시할 때마다, 자동화된 빌드 시스템이 작동하여 코드를 컴파일하고, 단위 및 통합 테스트를 실행한다. 이를 통해 버그를 조기에 발견하고 해결할 수 있다.
-
빈번한 통합: 개발자들은 하루에 여러 번 코드를 메인 브랜치에 통합한다. 이렇게 함으로써 코드 간의 충돌을 최소화하고, 소프트웨어의 안정성을 유지할 수 있다.
-
즉각적인 피드백: 자동화된 테스트와 빌드 과정을 통해 개발자는 코드의 문제를 즉시 발견하고 수정할 수 있다. 이는 개발 속도를 높이고, 소프트웨어의 품질을 개선한다.
CD (Continuous Deployment/Delivery, 지속적 배포/전달)
CD는 CI의 다음 단계로, 개발된 소프트웨어를 고객에게 신속하게 전달하는 것을 목표로 한다. CD는 두 가지 형태로 나뉜다: 지속적 배포(Continuous Deployment)와 지속적 전달(Continuous Delivery).
-
지속적 배포 (Continuous Deployment): 이 방식에서는 모든 코드 변경사항이 테스트를 거쳐 자동으로 생산 환경에 배포된다. 이는 매우 빠른 피드백 루프를 제공하며, 고객에게 지속적으로 새로운 기능을 제공할 수 있게 한다.
-
지속적 전달 (Continuous Delivery): 지속적 전달에서는 코드 변경사항이 자동으로 테스트되고 준비되지만, 최종적인 생산 환경으로의 배포는 수동으로 진행된다. 이 방법은 추가적인 검증 단계나 승인 과정을 통해 더 많은 제어를 제공한다.
CI/CD의 이점
- 버그 감소: 자동화된 테스트와 지속적인 통합을 통해 버그를 조기에 발견하고 해결한다.
- 개발 속도 향상: 지속적인 피드백과 빠른 반복을 통해 개발 프로세스가 가속화된다.
- 고객 만족도 향상: 지속적인 배포를 통해 빠르게 새로운 기능을 제공하고 고객의 요구에 신속하게 반응할 수 있다.
- 팀의 협업 향상: 모든 팀원이 코드베이스에 대해 더 잘 이해하고, 효율적으로 협업할 수 있다.
CI/CD는 소프트웨어 개발의 효율성과 품질을 극대화하기 위한 필수적인 접근법이다.
GitHub Actions를 사용한 CI/CD
GitHub Actions는 GitHub 저장소에서 CI/CD 파이프라인을 자동화할 수 있는 도구다. 워크플로우를 구성하여 소스 코드의 푸시 또는 풀 리퀘스트 같은 이벤트에 반응하도록 설정할 수 있다.
name: React CI/CD Pipeline
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v1
with:
node-version: '14'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
- name: Build
run: npm run build
deploy:
needs: build
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v1
with:
node-version: '14'
- name: Install dependencies
run: npm install
- name: Build
run: npm run build
- name: Deploy
run: # 배포 스크립트
이 예제에서는 React 애플리케이션을 빌드하고 테스트하는 과정을 정의한다. push와 pull_request 이벤트에 대해 반응하며, 먼저 의존성을 설치하고 테스트를 실행한 후, 애플리케이션을 빌드한다. 배포 단계에서는 빌드된 애플리케이션을 실제 서버나 클라우드에 배포하는 작업을 수행한다.
왜 GitHub Actions 을 사용했을까?
그것을 알아보기 위해선 대표적인 CI/CD 쪽의 Jenkins와 비교를 해봐야한다!!!
Jenkins vs GitHub Actions
Jenkins
장점
-
유연성과 맞춤 설정: Jenkins는 높은 수준의 유연성을 제공한다. 다양한 플러그인과 설정 옵션을 통해 거의 모든 종류의 CI/CD 워크플로우를 맞춤 설정할 수 있다.
-
강력한 플러그인 생태계: Jenkins는 방대한 플러그인 생태계를 가지고 있으며, 이는 다양한 개발, 테스트 및 배포 도구와의 통합을 가능하게 한다.
-
다양한 환경 지원: Jenkins는 거의 모든 운영 체제와 환경에서 실행될 수 있으며, 이는 Jenkins를 다양한 개발 환경에 적용 가능하게 만든다.
단점
-
설정 복잡성: Jenkins의 설정과 유지 관리는 복잡할 수 있다. 특히 맞춤 설정과 플러그인 관리가 초보자에게는 어려울 수 있다.
-
자체 서버 필요: Jenkins를 실행하기 위해서는 자체 서버가 필요하다. 이는 추가적인 유지 관리 작업과 비용을 발생시킬 수 있다.
-
초기 설정 시간: Jenkins를 처음 설정하는 데는 상당한 시간이 소요될 수 있다. 이는 프로젝트의 시작 단계에서 시간적 지연을 야기할 수 있다.
GitHub Actions
장점
-
내장된 CI/CD: GitHub Actions는 GitHub 플랫폼에 내장되어 있어 별도의 CI 도구를 설정할 필요가 없다. 이는 개발자가 소스 코드 관리와 CI/CD를 같은 플랫폼에서 관리할 수 있게 한다.
-
간단한 설정: GitHub Actions는 사용하기 쉽고 직관적인 워크플로우 구성을 제공한다. 이는 CI/CD를 신속하게 설정하고 실행할 수 있게 한다.
-
서버 없는 작업: 별도의 서버를 설정하거나 관리할 필요가 없으며, GitHub가 모든 인프라를 관리한다. 이는 유지 관리 부담을 줄여준다.
단점
-
GitHub에 종속적: GitHub Actions는 GitHub에 완전히 통합되어 있어 다른 VCS(버전 관리 시스템)나 CI 도구와의 연동이 제한적일 수 있다.
-
유연성과 확장성의 한계: Jenkins만큼의 고도의 유연성과 확장성을 제공하지 않는다. 복잡하고 맞춤화된 워크플로우가 필요한 경우 제한적일 수 있다.
-
자원 제한: GitHub Actions는 무료 계정에서는 제한된 자원을 제공한다. 큰 규모의 프로젝트나 복잡한 빌드 요구 사항을 가진 경우, 자원 제한에 부딪힐 수 있다.
그래서 왜 GitHub Actions 인가?
이번 프로젝트 상황에서 CI/CD 도구를 선택하는 데 있어 중요한 요소는 '간결성'과 '속도'이다. Jenkins와 GitHub Actions의 장단점을 고려해본 결과, 저는 GitHub Actions를 선택했다. 이 결정에는 GitHub Actions의 장점이 크게 와닿았다.
- 간단한 설정
- 내장된 CI/CD
- 시간 효율성
물론, Jenkins의 강력한 유연성과 맞춤 설정 기능도 매력적이지만, 현재의 프로젝트 요구사항과 제 개인적인 역량을 고려할 때 GitHub Actions가 더 적합한 선택이었다. 특히, 데브옵스에 대한 깊은 전문 지식이 없는 상황에서 GitHub Actions의 직관성과 간편함은 큰 장점으로 작용했다.
이렇게 GitHub Actions를 선택한 것은 저의 개발 환경과 요구사항에 가장 잘 부합하는 결정이었으며, 이를 통해 프로젝트의 CI/CD 파이프라인을 원활하고 효율적으로 관리할 수 있게 되었다.
