배포 자동화

명령어 입력이나 간단한 클릭을 통해 전체 배포 과정을 자동으로 진행하는 것

배포 자동화를 사용하게 될 경우 시간절약 이 가능하고, Human Error 를 방지할 수 있다.

• Human Error : 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수

배포 자동화 Pipieline

Pipline?

소스 코드 관리부터 실제 서비스로의 배포 과정을 연결하는 구조

• 전체 배포 과정을 여러 단계로 분리 (단계별 순차적으로 주어진 작업(Action)들을 수행)

단계

1. Source

원격 저장소 소스 코드에 변경 사항 발생
→ 이를 감지하고 다음 단계로 전달하는 작업 수행

2. Build

Source 단계에서 전달 받은 코드를 컴파일, 빌드, 테스트하여 가공 & 생성된 결과물을 다음 단계로 전달하는 작업 수행

3. Deploy

Build 단계에서 전달받은 결과물을 실제 서비스에 반영하는 작업 수행

CI / CD

CI : 지속적 통합 (Continuous Integration)
CD : 지속적 배포 (Continuous Delivery/Deployment)

CI / CD Pipeline

• CI : plan → code → build → test
• CD : release → deploy → operate → plan

CI (지속적 통합)

팀 구성원이 각자의 작업을 자주 통합하는 SW방식

모든 코드 변화를 하나의 Repository에서 관리하는 것 부터 시작한다.잦은 pull request & merge 로 코드를 자주 통합하며 (기본적인 테스트도 작동 가능) 각 개발한 코드를 이른 시점에 자주 합치고, 자주 테스트를 해볼 수 있어 효율적인 개발이 가능하다.

1. 코드 변경사항을 주기적으로 빈번하게 머지해야 한다.

• 새로운 기능을 구현할때 기능을 어떻게 작은 단위로 나눠서 메인 repository에 반영할것인지, 작은 단위로 나눠서 사용자에게 배포할 수 있을지 최대한 작은 단위로 나누어서 개발하고 통합해 나가는 것이 중요하다.
  

2. 통합을 위한 단계 (빌드, 테스트, 머지)의 자동화

• 주기적으로 머지된 이 코드의 변경사항이 자동으로 빌드가 되어서 코드 변경사항 이후에도 빌드가 성공적으로 되는지 확인되어야한다.
• 새로 추가된 이 코드의 변경사항 뿐만 아니라 기존의 시스템에 다른 버그를 발생시키지는 않았는지 자동으로 테스트까지 되어야 한다.
  

• Code: 개발자가 코드를 코드 저장소에 Push
• Build: 코드 저장소로부터 코드를 가져와서 (Unit Test 후) Build
• (Test): 코드 Build 결과물이 다른 컴포넌트와 잘 통합되는지 확인

build? 개발자만 읽을 수 있는 소스 코드를 실행 가능한 코드 / 프로그램으로 변환하는 과정
번들링? 브라우저가 소스 코드를 더 잘 읽을 수 있게 도와주며, 빌드과정 중 하나이다.

CD (지속적 배포)

CI 과정이 원할히 끝나면 바로 고객에게 배포하는 것 (ex- Github Page)

• release : Build 까지 모두 준비 완료! → 어떤 기능이 개발되었는지 비지니스 관계자들과 이야기 나누는 단계
• deploy : 실제 배포 단계
• operation : 배포된 SW를 실제 운용하는 과정 (고객 피드백을 받아 기획에 반영)