CI/CD는 자주 접해본 단어인데 소규모 프로젝트만 해보면서 되게 멀게만 느껴졌던 단어였다. Wouldyouguess? 프로젝트를 진행하면서 팀원 형님이 CI/CD를 구축하는 모습을 보면서 '아 어렵구나...'라고만 생각했었다. 구축이 된 이후에는 '아 편하구나...'라고 느꼈는데 이번을 기회로 차근차근 내용을 습득해보고자 한다.
1. CI/CD란?
일반적인 애플리케이션 개발 단계
개발(develop) → 빌드(build) → 테스트(test) → 릴리즈(release) → 배포(deploy)
CI/CD는 `지속적 통합(Continuous Integration)` / `지속적 배포(Continuous Deployment) or 지속적 제공(Continuous Delivery)`의 줄임말로, `CI`는 빌드 및 테스트 자동화 과정, `CD`는 배포 자동화 과정을 말합니다.
- CI : 지속적인 통합으로 새로운 코드가 작성됐을 때 주기적으로 빌드 및 테스트가 진행되면서 공유되는 `repository`에 `merge`되는 것
- CD : 지속적인 배포(제공)으로 CI단계를 거친 코드를 실제 운영 서버에 자동 배포하는 것
⭐️ CI/CD = 자동화(개발 + 빌드 + 테스트 + 배포)
2. 지속적 통합, CI(Continuous Integration)
개발자는 형상관리 시스템(github 등)에 코드를 커밋하고 통합합니다. 통합한 코드를 빌드하고 테스트하여 버그가 발생하면 버그를 해결합니다. 이 과정에서 빌드와 테스트를 자동화하면 아래와 같은 장점이 있습니다.
- 여러 개발자가 관련된 코드를 작업하여 발생하는 충돌 문제를 해결할 수 있다.
- 커밋할 때마다 빌드와 테스트가 자동으로 이루어져 잘못된 merge를 예방할 수 있다.
- 코드 검증에 들어가는 시간이 줄어들며 개발 편의성이 좋아진다.
`repository`의 특정 브랜치에 `push`가 되거나, `Pull Request`를 요청했을 때를 확인하여 코드 테스트 및 통합을 할 수 있도록 합니다.
CI 파이프라인의 주요 단계
1. 코드 체크아웃 : 소스 코드를 가져옵니다
2. 의존성 설치 : 필요한 라이브러리와 도구를 설치합니다
3. 코드 분석 : 정적 코드 분석을 통해 코드 품질을 검사합니다
4. 단위 테스트 : 개별 컴포넌트의 기능을 테스트합니다
5. 통합 테스트 : 여러 컴포넌트 간의 상호작용을 테스트합니다
6. 아티팩트 생성 : 배포 가능한 결과물을 만듭니다
3. 지속적 배포(제공), CD(Continuous Deployment, Continuous Delivery)
`repository`에 통합된 코드가 CI 단계를 마치고 아티팩트를 생성했다면 해당 코드를 배포할 준비가 됐습니다. 이 코드를 자동으로 배포하여 사용자는 항상 최신 버전의 서비스를 사용할 수 있게 됩니다. 배포를 자동화 함으로써 일일이 배포하지 않아도 되며, 배포보다 개발에 집중할 수 있습니다.
하지만, 지속적 배포(Deployment)와 지속적 제공(Delivery)는 차이점이 있습니다.
지속적 배포(Continuous Deployment)
- CI를 마치고 릴리즈가 가능한 상태라면 배포까지 자동으로 해주는 것
- 프로덕션 환경까지 완전 자동화된 배포
- 수동 개입 없이 자동으로 진행
지속적 제공(Continuous Delivery)
- CI를 마치고 릴리즈가 가능한 상태라면 사람의 검증을 통해 수동으로 배포하는 것
- 프로덕션 환경으로의 배포는 수동으로 진행
- 비즈니스 결정에 따라 배포 시기 결정
CD 파이프라인의 일반적인 단계
1. 스테이징 환경 배포 : 프로덕션과 유사한 환경에 애플리케이션을 배포하는 단계
2. smoke 테스트 : 애플리케이션의 핵심 기능이 정상 작동하는지 빠르게 확인하는 기본적인 테스트
3. 성능 테스트 : 애플리케이션의 성능 지표를 측정하고 검증(로드 테스트, 스트레스 테스트)
4. 보안 검사 : 보안 취약점 스캐닝
5. 프로덕션 환경 : 실제 사용자가 접근하는 환경에 애플리케이션 배포
6. 배포 모니터링 : 배포 후 애플리케이션 건강 상태 확인
4. CI/CD 도구 결정
프론트엔드 CI/CD 파이프라인을 구축할 때 고려해야 할 주요 도구로는 Jenkins, Travis CI, CircleCI, Github Actions 등이 있습니다.
- Jenkins : 오픈 소스 자동화 서버로, 다양한 플러그인을 통해 확장성이 뛰어납니다. 복잡한 파이프라인을 구성할 수 있지만, 설정과 관리가 상대적으로 복잡할 수 있습니다.
- Travis CI, CircleCI : 클라우드 기반 CI/CD 서비스로, 설정이 간단하고 Github와의 통합이 용이합니다. 특히, 소규모 프로젝트나 간단한 파이프라인 구축에 적합합니다.
- Github Actions : Github repository 내에서 직접 CI/CD 파이프라인을 구성할 수 있는 기능을 제공합니다. Github와의 뛰어난 통합과 사용의 용이성으로 인기가 많습니다.
대부분의 작업코드를 Github를 통해 관리하기 때문에 `Github Actions`을 사용해려고 합니다.
특정 Repository에서 어떠한 이벤트가 발생했을 때 실행할 작업을 설정할 수 있습니다.(PR 생성, 특정 브랜치에 push 등)
'프론트엔드' 카테고리의 다른 글
[CI/CD] CloudFront 연동하기 (0) | 2024.12.01 |
---|---|
[CI/CD] Github Actions로 CI/CD 구축하기 (0) | 2024.11.29 |
[모던 자바스크립트 Deep Dive] 08장 - 제어문 (0) | 2024.11.22 |
[프론트엔드] reflow, repaint (0) | 2024.11.14 |
[shadcn/ui] shadcn/ui란? (0) | 2024.11.12 |
CI/CD는 자주 접해본 단어인데 소규모 프로젝트만 해보면서 되게 멀게만 느껴졌던 단어였다. Wouldyouguess? 프로젝트를 진행하면서 팀원 형님이 CI/CD를 구축하는 모습을 보면서 '아 어렵구나...'라고만 생각했었다. 구축이 된 이후에는 '아 편하구나...'라고 느꼈는데 이번을 기회로 차근차근 내용을 습득해보고자 한다.
1. CI/CD란?
일반적인 애플리케이션 개발 단계
개발(develop) → 빌드(build) → 테스트(test) → 릴리즈(release) → 배포(deploy)
CI/CD는 지속적 통합(Continuous Integration)
/ 지속적 배포(Continuous Deployment) or 지속적 제공(Continuous Delivery)
의 줄임말로, CI
는 빌드 및 테스트 자동화 과정, CD
는 배포 자동화 과정을 말합니다.
- CI : 지속적인 통합으로 새로운 코드가 작성됐을 때 주기적으로 빌드 및 테스트가 진행되면서 공유되는
repository
에merge
되는 것 - CD : 지속적인 배포(제공)으로 CI단계를 거친 코드를 실제 운영 서버에 자동 배포하는 것
⭐️ CI/CD = 자동화(개발 + 빌드 + 테스트 + 배포)
2. 지속적 통합, CI(Continuous Integration)
개발자는 형상관리 시스템(github 등)에 코드를 커밋하고 통합합니다. 통합한 코드를 빌드하고 테스트하여 버그가 발생하면 버그를 해결합니다. 이 과정에서 빌드와 테스트를 자동화하면 아래와 같은 장점이 있습니다.
- 여러 개발자가 관련된 코드를 작업하여 발생하는 충돌 문제를 해결할 수 있다.
- 커밋할 때마다 빌드와 테스트가 자동으로 이루어져 잘못된 merge를 예방할 수 있다.
- 코드 검증에 들어가는 시간이 줄어들며 개발 편의성이 좋아진다.
repository
의 특정 브랜치에 push
가 되거나, Pull Request
를 요청했을 때를 확인하여 코드 테스트 및 통합을 할 수 있도록 합니다.
CI 파이프라인의 주요 단계
1. 코드 체크아웃 : 소스 코드를 가져옵니다
2. 의존성 설치 : 필요한 라이브러리와 도구를 설치합니다
3. 코드 분석 : 정적 코드 분석을 통해 코드 품질을 검사합니다
4. 단위 테스트 : 개별 컴포넌트의 기능을 테스트합니다
5. 통합 테스트 : 여러 컴포넌트 간의 상호작용을 테스트합니다
6. 아티팩트 생성 : 배포 가능한 결과물을 만듭니다
3. 지속적 배포(제공), CD(Continuous Deployment, Continuous Delivery)
repository
에 통합된 코드가 CI 단계를 마치고 아티팩트를 생성했다면 해당 코드를 배포할 준비가 됐습니다. 이 코드를 자동으로 배포하여 사용자는 항상 최신 버전의 서비스를 사용할 수 있게 됩니다. 배포를 자동화 함으로써 일일이 배포하지 않아도 되며, 배포보다 개발에 집중할 수 있습니다.
하지만, 지속적 배포(Deployment)와 지속적 제공(Delivery)는 차이점이 있습니다.
지속적 배포(Continuous Deployment)
- CI를 마치고 릴리즈가 가능한 상태라면 배포까지 자동으로 해주는 것
- 프로덕션 환경까지 완전 자동화된 배포
- 수동 개입 없이 자동으로 진행
지속적 제공(Continuous Delivery)
- CI를 마치고 릴리즈가 가능한 상태라면 사람의 검증을 통해 수동으로 배포하는 것
- 프로덕션 환경으로의 배포는 수동으로 진행
- 비즈니스 결정에 따라 배포 시기 결정
CD 파이프라인의 일반적인 단계
1. 스테이징 환경 배포 : 프로덕션과 유사한 환경에 애플리케이션을 배포하는 단계
2. smoke 테스트 : 애플리케이션의 핵심 기능이 정상 작동하는지 빠르게 확인하는 기본적인 테스트
3. 성능 테스트 : 애플리케이션의 성능 지표를 측정하고 검증(로드 테스트, 스트레스 테스트)
4. 보안 검사 : 보안 취약점 스캐닝
5. 프로덕션 환경 : 실제 사용자가 접근하는 환경에 애플리케이션 배포
6. 배포 모니터링 : 배포 후 애플리케이션 건강 상태 확인
4. CI/CD 도구 결정
프론트엔드 CI/CD 파이프라인을 구축할 때 고려해야 할 주요 도구로는 Jenkins, Travis CI, CircleCI, Github Actions 등이 있습니다.
- Jenkins : 오픈 소스 자동화 서버로, 다양한 플러그인을 통해 확장성이 뛰어납니다. 복잡한 파이프라인을 구성할 수 있지만, 설정과 관리가 상대적으로 복잡할 수 있습니다.
- Travis CI, CircleCI : 클라우드 기반 CI/CD 서비스로, 설정이 간단하고 Github와의 통합이 용이합니다. 특히, 소규모 프로젝트나 간단한 파이프라인 구축에 적합합니다.
- Github Actions : Github repository 내에서 직접 CI/CD 파이프라인을 구성할 수 있는 기능을 제공합니다. Github와의 뛰어난 통합과 사용의 용이성으로 인기가 많습니다.
대부분의 작업코드를 Github를 통해 관리하기 때문에 Github Actions
을 사용해려고 합니다.
특정 Repository에서 어떠한 이벤트가 발생했을 때 실행할 작업을 설정할 수 있습니다.(PR 생성, 특정 브랜치에 push 등)
'프론트엔드' 카테고리의 다른 글
[CI/CD] CloudFront 연동하기 (0) | 2024.12.01 |
---|---|
[CI/CD] Github Actions로 CI/CD 구축하기 (0) | 2024.11.29 |
[모던 자바스크립트 Deep Dive] 08장 - 제어문 (0) | 2024.11.22 |
[프론트엔드] reflow, repaint (0) | 2024.11.14 |
[shadcn/ui] shadcn/ui란? (0) | 2024.11.12 |