배포 자동화
배포 자동화란 한번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 뜻한다.
배포 자동화가 필요한 이유
- 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약된다.
- 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수 휴먼 에러를 방지할 수 있다. 그 전에 했던 배포 과정과 비교하여 특정 과정을 생략하거나 다르게 진행하여 오류가 발생하는 것이 휴먼 에러의 예이다.
- 배포 자동화를 통해 전체 배포 과정을 일관되게 진행하는 구조를 설계하여 휴먼 에러 발생 가능성을 낮출 수 있다.
배포 자동화 파이프라인
배포에서 파이프라인이란 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 말한다. 파이프라인은 전체 배포 과정을 여러 단계로 분리한다. 각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업들을 수행한다.
1. Source 단계: source 단계는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행한다.
2. Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.
3. Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.
CI/CD 파이프라인
지속적 통합 (CI; continuous integration)
CI는 지속적 통합의 약자로 팀 구성원이 각자의 작업을 자주 통합하는 소프트웨어 개발 방식이다.
CI 세가지 단계
- Code: 개발자가 코드를 코드 저장소에 Push한다.
- Build: 코드 저장소로부터 코드를 가져와서 (유닛 테스트 후) 빌드한다.
- Test: 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인한다.
빌드는 개발자만 읽을 수 있는 소스 코드를 실행 가능한 코드 및 프로그램으로 변환하는 과정이다. 번들링도 브라우저가 소스 코드를 잘 읽을 수 있게 도와줌으로 빌드이 과정 중 하나로 볼 수 있다. 두 용어 모두 Build로 통용되기도 한다.
지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작한다. 모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있다. 그리고 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합한다. 신중하게 고민하고 통합하기 보다는, 자주 통합하여 더 자주 실패하고 문제를 더 빠르게 찾을 수 있다.지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있게 해당 이슈를 빠르게 개선할 수 있다. 지속적 통합이 적용된 개발팀은 코드를 머지하기 전, 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있게된다.