배포 자동화

배포 자동화란 한번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 뜻합니다. 배포 자동화가 왜 필요할까요?

수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약되며,
휴먼 에러(Human Error)를 방지할 수 있습니다.
배포 자동화를 통해 전체 배포 과정을 매번 일관되게 진행하는 구조를 설계하여 휴먼 에러 발생 가능성을 낮출 수 있습니다.

배포 자동화 파이프라인

배포에서 파이프라인(Pipeline)이란 용어는
소스 코드의 관리부터 실제 서비스로의 배포 과정을
연결하는 구조를 뜻합니다.

파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리합니다.
각 단계는 파이프라인 안에서 순차적으로 실행되며,
각 단계마다 주어진 작업(Actions)들을 수행합니다.

파이프라인을 여러 단계로 분리할 때,
대표적으로 쓰이는 세 가지 단계가 있습니다.

• Source 단계
  Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행합니다.

• Build 단계
  Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공합니다.
  또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행합니다.

• Deploy 단계
  Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행합니다.

파이프라인의 단계는 필요에 따라 더 세분화되거나 간소화될 수 있습니다. DevOps를 전문으로 학습하는 경우 아래와 같이 파이프라인의 단계를 세분화해서 나누기도 합니다.
또한, 해당 툴을 소개하는 업체에 따라 용어를 미묘하게 다르게 사용하기도 합니다.

CI/CD 파이프라인

지속적 통합 (CI)

지속적 통합은
팀 구성원이 각자의 작업을 자주 통합하는 소프트웨어 개발 방식입니다.
CI는 크게 세 가지 단계로 나뉩니다.

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

빌드는 개발자만 읽을수 있는 소스 코드를 실행 가능한 코드 및 프로그램으로 변환하는 과정입니다.
번들링도 브라우저가 소스 코드를 더 잘 읽을 수 있게 도와줌으로, 빌드의 과정 중 하나로 볼 수 있습니다.
종종 두 용어 모두 "빌드"로 통용되기도 합니다.

지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작합니다.
모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있습니다.
그리고 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합합니다.
이 때, 기본적인 테스트도 작동시킬 수 있다. 이렇게 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에, 자주 합치고, 자주 테스트 해볼 수 있습니다.
지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있습니다.

지속적 배포 (CD)

지속적 배포는
지속적 통합 과정이 원활하게 끝나면 바로 고객에게 배포하는 방식입니다.

지속적 배포는 크게 3가지 과정으로 나눌 수 있습니다.

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

최근에는 클라우드 기술 발전과 맞물려 지속적 통합과 지속적 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있다.

예를 들어, 이전에는 배포 자체가 상당히 오래 걸리고 힘든 일이어서 릴리즈 단계에서 많은 고민을 하곤 했습니다.
서버를 전부 재시작해야 한다거나, 일부 기능을 제공하지 못하는 경우도 많았기 때문입니다.
요즘은 고객의 피드백을 빨리 받기 위해서라도, 서비스를 중단하지 않기 위해서라도 버전 릴리즈만 잘 기록해두고 바로바로 배포하는 사례가 증가하고 있습니다.

실리콘밸리 테크 기업들은 다양한 모니터링 툴과 장애 대응 프로세스를 마련해 배포에 대한 자신감을 높여 조직의 비즈니스 역량을 키우고 있습니다.
“하루에 1,000번의 배포를 할 수 있는가?” 가 조직의 기술적 확장 역량을 판단할 수 있는 중요한 지표가 되고 있습니다.