Chapter1. 배포 자동화

1-1. 지속적 통합
1-2. 지속적 배포

---

Chapter1. 배포 자동화

한번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것

• 시간 절약
• 휴먼 에러(Human Error) 방지
  • 휴먼 에러 : 사람이 수동적으로 배포 과정을 진행하는 중 생기는 실수
  • 전체 배포 과정을 일관되게 진행하는 구조를 설계한 배포 자동화를 통해 휴먼에러 발생 가능성을 낮춤

✨ 배포 자동화 파이프라인(Pipeline)

• 파이프라인(Pipeline) : 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조
  • 배포 과정 단계(Stages) : 순차적 실행
    1. Source 단계: 원격 저장소의 소스 코드에 변경 사항이 생기면 이를 감지하고 다음 단계로 전달하는 작업을 수행
    2. Build 단계: Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행
    3. Deploy 단계: Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행

---

📌 지속적 통합(CI; Continuous Integration)

팀 구성원이 각자의 작업을 자주 통합하는 소프트웨어 개발 방식

모든 코드 변화를 하나의 리포지토리에서 관리한다.
각자 개발한 코드를 풀 리퀘스트(pull request)와 머지(merge)로 자주 통합하고 테스트하며 문제점을 파악한다.

• CI 단계
• Code: 개발자가 코드를 코드 저장소에 Push한다.
• Build: 코드 저장소로부터 코드를 가져와서 (유닛 테스트 후) 빌드한다.
  • 개발자만 읽을 수 있는 소스코드를 실행 가능한 코드 및 프로그램으로 변환하는 과정.
• (Test): 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인한다.

📌 지속적 배포 (CD; Continuous Delivery, Deployment)

지속적 통합 과정이 원활하게 끝나면 바로 고객에게 배포하는 것

• CD 단계
• Release: 빌드까지 모두 준비가 되었고, 어떤 기능이 개발되었는지 비즈니스 관계자들과 이야기를 나누는 단계. 어떤 기능을 넣을지, 해당 릴리즈는 배포를 할지 말지 결정하는 단계로 여러 의사결정이 이루어진다.
• Deploy: 실제 배포
• Operation: 배포된 소프트웨어를 실제 운용하는 과정. 해당 과정에서 고객의 피드백을 충분히 받아 기획에 반영한다.
  
  

지속적 배포 사례 : Github Page

지정해둔 디렉터리에 커밋만 하면,
Github Page가 알아서 index.html 파일과 해당 디렉터리에 있는 파일을 잘 번들링해서 Github Page 서버에 업로드한다.