지속적 배포

자동 테스트를 통과한 변경을 전부 프로덕션까지 내보내기로 한 방식입니다. 어느 변경을 내보낼지 사람이 고르는 자리가 없습니다. 커밋이 테스트를 통과하면 그대로 사용자에게 갑니다.

상세

지속적 배포(Continuous Deployment)를 특별하게 만드는 것은 자동 테스트를 통과한 모든 변경을 프로덕션에 배포한다는 점입니다. Jez Humble 은 여기에 짧은 QA 관문(Quality Assurance, 품질 보증)이 선택적으로 끼어들 수 있다고 적습니다. 통과한 것 중 일부만 골라 내보내면 이 이름이 붙지 않습니다.

배포와 릴리스는 같은 말이 아닙니다. Humble 은 UAT(User Acceptance Test, 사용자 인수 테스트)로 계속 배포하는 것은 큰일이 아니라고 적습니다. 계속 배포한다는 사실만으로는 부족합니다. 프로덕션까지 간다는 것이 조건입니다. 통과한 변경이 전부 간다는 것도 조건입니다. Humble 은 지속적 배포를 좋은 빌드(every good build)를 전부 사용자에게 릴리스하는 실천이라고 적습니다. 더 정확한 이름은 지속적 릴리스(continuous release)였을 수도 있다고 덧붙입니다.

GitHub 문서는 지속적 배포를 자동화를 써서 소프트웨어 업데이트를 게시하고 배포하는 실천이라고 적습니다. 전형적인 절차에서 코드는 배포 전에 자동으로 빌드되고 테스트됩니다. 지속적 배포가 지속적 통합과 자주 함께 놓인다고도 적습니다.

flowchart TD
    A[커밋] --> B[자동 테스트]
    B -->|통과| C[짧은 QA 관문 · 선택]
    C --> D[프로덕션]
    B -->|실패| E[여기서 멈춤]

커밋이 들어오면 자동 테스트가 돌고, 통과한 것이 프로덕션으로 넘어갑니다. 통과하지 못한 변경은 그 자리에서 멈춥니다. 사람이 승인하는 칸은 이 경로에 없습니다.

대가

릴리스를 막는 자리가 자동 테스트 하나로 줄어듭니다. 통과한 변경은 전부 프로덕션으로 갑니다. 테스트가 걸러내지 못한 변경을 걸러 낼 다음 관문이 뒤에 없습니다.

파이프라인을 상시로 그 상태에 두어야 합니다. Humble 은 통과한 빌드를 전부 릴리스할 수 없을 때 스토리가 완료라는 것이 무엇인지 물으면서, 최소한 다음 조건들이 적용되어야 한다고 적습니다. 스토리가 든 빌드에 전체 테스트 스위트를 돌렸을 것. 이것이 효율을 내려면 단위·컴포넌트·인수 수준의 포괄적 자동 테스트가 있어야 한다는 뜻이라고 적습니다. 스토리가 프로덕션 유사 환경에서 고객에게 시연됐을 것. 프로덕션 유사란 이치에 닿는 범위 안에서 프로덕션과 동일하다는 뜻입니다. 프로덕션 배포에 걸림돌이 없을 것. 용량·가용성·보안 같은 교차 기능 특성까지 테스트했다는 뜻입니다. SOA(Service-Oriented Architecture, 서비스 지향 아키텍처)를 쓰는 자리도 마찬가지입니다. 애플리케이션과 다른 시스템 사이에 의존이 있으면 통합 문제가 없어야 한다는 뜻입니다.

이 조건들은 Humble 이 지속적 전달 쪽에 걸어 둔 것입니다. 같은 글이 지속적 배포는 지속적 전달을 함의한다고 적으므로, 지속적 배포를 고른 쪽은 이 조건들을 그대로 집니다.

환경이 한 벌 더 붙습니다. Humble 은 거대한 클러스터에 배포하는 자리에서도 블루그린 배포 같은 기법을 쓰면 사용자에게 영향을 주지 않고 프로덕션 환경에서 다른 판을 나란히 돌릴 수 있다고 적습니다. 프로덕션과 동일한 자리를 상시로 내주는 일이 여기 따라옵니다.

릴리스 시점을 고르는 손잡이가 사라집니다. Humble 은 지속적 전달을 릴리스 일정을 IT 가 아니라 사업의 손에 두는 것이라고 적습니다. 지속적 배포는 통과한 빌드를 전부 릴리스하므로 그 손에 남는 선택이 없습니다.

그래서 못 고르는 자리가 있습니다. Humble 은 통과한 빌드를 전부 사용자에게 릴리스하는 것이 언제나 말이 되지는 않는다고 적습니다. 소프트웨어 변경과 하드웨어 변경이 묶여 있는 임베디드 제품에서는 이것이 대개 불가능합니다. COTS(Commercial Off-The-Shelf, 상용 기성품) 세계에서는 어느 시점에든 릴리스된 판이 몇 개를 넘지 않기를 바랄 마케팅·지원 쪽 이유가 있습니다. 그런 자리에서도 Eclipse 나 Omni Group 처럼 개발자 빌드나 얼리 액세스 빌드는 따로 낼 수 있다고 덧붙입니다. 다른 그럴 만한 이유들도 아마 있고, 중요한 것은 그 이유가 사업상의 이유여야 한다는 점이라고 적습니다.

이름의 출처

지속적 배포라는 이름이 실린 원전으로 Humble 이 가리키는 것은 Timothy Fitz 의 2009년 2월 10일 글입니다. 제목은 "Continuous Deployment at IMVU: Doing the impossible fifty times a day." 입니다. 글은 https://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ 에 있습니다. Fitz 본인은 이것이 새로운 기법이 아니라고 적습니다. IMVU 에서 자신이 합류하기 훨씬 전부터 여러 해 동안 해 오던 일이라고 덧붙입니다.

Fitz 는 이 글에서 앞서 자신이 지속적 배포에 대해 쓴 글을 가리킵니다. 그것을 코드 변경을 가능한 한 빠르게 프로덕션에 배포하는 일이라고 적습니다. 지속적 배포가 추상적인 이론이 아니라고 적습니다. IMVU 에서는 출하하는 것이 문화의 핵심이라고 적습니다. 절차는 네 줄입니다. 지속적으로 통합합니다. 커밋할 때마다 모든 테스트를 자동으로 돌립니다. 테스트가 통과하면 클러스터에 배포합니다. 배포가 성공하면 반복합니다.

Jez Humble 은 2010년 8월 13일 글에서 이 순서를 직접 가리킵니다. Timothy Fitz 의 지속적 배포 블로그 글이 자신과 Dave 가 지속적 전달 책을 내기 1년도 더 전에 나왔다고 적고, 그러면 왜 다른 이름을 골랐는지, 실제로 차이가 있는 것인지 스스로 묻습니다. 이름이 둘로 갈린 자리가 여기입니다.

예시

GitHub Actions 문서가 배포 잡의 형태를 이렇게 적습니다.

YAML

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    concurrency: production
    steps:
      - name: deploy
        # ...deployment-specific steps

on: push: branches: - main 이 방아쇠입니다. main 브랜치에 푸시가 들어오면 이 워크플로가 돕니다. 사람이 실행을 거는 칸은 이 파일에 없습니다. environment: production 은 이 잡에 붙은 환경 이름입니다. concurrency: production 은 잡 수준에 지정한 동시성입니다. 문서는 잡 수준에도 동시성을 지정할 수 있다고 적습니다. 그러면 동시성에 걸린 잡이 대기 중이어도 워크플로의 다른 잡들은 진행할 수 있다고 적습니다. 원문은 https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments 에 있습니다.

경계

지속적 전달과 같은 것인가. 아닙니다.

Humble 은 지속적 배포가 지속적 전달을 함의하지만 그 역은 참이 아니라고 적습니다. 지속적 배포를 하고 있으면 지속적 전달을 하고 있는 것입니다. 지속적 전달을 하고 있다고 해서 지속적 배포를 하고 있는 것은 아닙니다.

가르는 자리는 버튼입니다. Humble 은 지속적 전달을 구현한다는 것이 소프트웨어가 생애 전체에 걸쳐 언제나 프로덕션 준비 상태라는 뜻이라고 적습니다. 어떤 빌드든 완전 자동 절차로 버튼 한 번에 몇 초나 몇 분 안에 사용자에게 릴리스될 수 있다는 뜻입니다. 누를 버튼이 남아 있으면 지속적 전달입니다. 그 버튼이 없으면 지속적 배포입니다. 통과한 변경이 전부 프로덕션으로 나갑니다.

지속적 배포

상세

대가

이름의 출처

예시

경계

관련 항목

이것이 거치는 처리 단계

이것이 배포·전달되는 경로

헷갈리는 이웃

프로덕션에 내보내는 방식

릴리스 준비 상태의 조건

완전 배포를 벗어나는 예외 사례

상세

대가

이름의 출처

예시

경계

관련 항목

이것이 거치는 처리 단계

이것이 배포·전달되는 경로

헷갈리는 이웃

프로덕션에 내보내는 방식

릴리스 준비 상태의 조건

완전 배포를 벗어나는 예외 사례

이 용어를 쓴 노트 1