CI/CD와 클라이언트 배포

전형호·2023년 4월 3일

클라이언트 배포

로컬 환경에서 개발한 코드를 실제 서비스로 만들기 위해서는, 빌드 과정과 이를 웹에 노출시키는 배포 과정이 필요하다.
→ 빌드를 통해 만든 정적 파일이 웹을 통해 제공(serve)되려면 정적 파일을 제공할 웹 서버가 필요하다.

호스팅 서비스

정적 파일을 제공할 수 있도록 서버의 공간을 대여 해주는 서비스
호스팅 서비스를 통해서 단순(정적) 파일을 배포할 수 있다

다양한 웹 호스팅 서비스

Amazon Web Service (AWS) S3
Google Cloud Storage
Vercel
GitHub Pages
Netlify
Heroku

CI(지속적 통합)

어플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어
공유 레포지토리에 통합히는 것을 의미한다.

지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다. 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다. 지속적 통합은 그 자체로 유익하지만 CI/CD 파이프라인을 구현하기 위한 첫 번째 단계이기도 한다.

Code - Build - Test 단계에서 꾀할 수 있다.

1) Code

개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계

2) Build

원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계

3) Test

코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

CI의 핵심 목표

버그를 신속하게 찾아 해결하고,
소프트웨어의 품질을 개선하고,
새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는 것에 있다.

CD(지속적 배포)

개발자의 변경 사항이 레포지토리를 넘어, 고객의 프로덕션(Production) 환경까지 릴리즈 되는 것이다.

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올린다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포된다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다.

지속적 배포는 또한 성숙하고 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 한다. 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포된다. 강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도 여러 번 이루어지는 릴리스가 특별하지 않은 일상이 된다.

Release - Deploy - Operate 단계에서 꾀할 수 있다.

1) Release
배포 가능한 소프트웨어 패키지를 작성한다.

2) Deploy
프로비저닝을 실행하고 서비스를 사용자에게 노출합니다. 실질적인 배포 부분이다.

3) Operate
서비스 현황을 파악하고 생길 수 있는 문제를 감지한다.

CD의 핵심 목표

서비스의 개발팀과 비즈니스팀(영업, CS팀 등) 간의 커뮤니케이션 부족 문제를 해결해 줌으로써, 배포에 이르기까지의 노력을 최소한으로 단축시켜 준다는 Benefit을 제공한다.

CI/CD 파이프라인

배포에서 파이프라인(Pipeline)이란 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다.
파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리하며, 각 단계는 파이프라인 안에서 순차적으로 실행되고, 각 단계마다 주어진 작업(Actions)들을 수행한다.