추가 적립 안내

효과적이고 지속적인 소프트웨어 개발의 모든 것 『신뢰할 수 있는 소프트웨어 출시』. 소프트웨어의 고객 인도과정에서 발생하는 여러 어려움을 효과적으로 다루기 위한 기술과 사례를 설명하는 책이다. 빌드, 기능·성능 테스트, 배포, 출시의 전체 단계를 자동화하는 기술과 소프트웨어 개발에 참여하는 개발자, 기획자, QA, 운영자가 효과적으로 협업할 수 있는 방법을 구체적으로 다룬다.

★ 요약 ★
(2013년 11월 초판과 동일한 내용의 도서입니다.)
이 책은 소프트웨어의 고객 인도과정에서 발생하는 여러 어려움을 효과적으로 다루기 위한 기술과 사례를 설명한다. 빌드, 기능/성능 테스트, 배포, 출시의 전체 단계를 자동화하는 기술과 소프트웨어 개발에 참여하는 개발자, 기획자, QA, 운영자가 효과적으로 협업할 수 있는 방법을 구체적으로 다룬다. 또한 최적화된 개발 및 배포 프로세스도 소개하므로 독자는 이를 활용해 조직 상황에 적합한 프로세스를 디자인하고 적용한 뒤 발전시켜 나갈 수 있다. 개발자, QA, 운영자, 관리자 모두 반드시 읽고, 익히고, 실천해야 할 필독서다.

★ 이 책에서 다루는 내용 ★

■ 소프트웨어 빌드, 통합, 테스트, 배포의 전면 자동화
■ 팀과 조직 단계에서의 배포 파이프라인 구현
■ 개발자, 테스터, 운영자 간의 협업 개선
■ 효과적인 설정 관리 전략 구현
■ 분석부터 구현까지 인수 테스트 자동화
■ 용량과 기타 비기능 요구사항 테스트
■ 지속적 배포와 무정지 출시 구현
■ 인프라, 데이터, 컴포넌트, 의존성 관리
■ 위험 관리, 순응, 감사 다루기

★ 이 책의 대상 독자 ★

이 책의 주요 목적 중 하나는 소프트웨어 배포의 책임을 갖는 관련자들의 협업을 개선하는 데 있다. 특히 개발자, 테스터, 시스템과 데이터베이스 관리자, 관리자를 염두에 두었다.
전통적인 설정 관리 문제, 소스 코드 관리, 출시 계획, 검수, 규정 준수에서 빌드 자동화, 테스트, 배포 프로세스의 통합까지를 주제로 다룬다. 자동화 인수 테스트, 의존성 관리, 데이터베이스 마이그레이션, 테스트와 실환경 생성과 관리 기술 또한 다룬다.

소프트웨어 개발에 참여하는 많은 사람이 이런 활동을 코드 작성보다 덜 중요하다고 생각한다. 하지만 경험에 따르면 이 작업에 많은 시간과 노력을 들이는 것이 성공적인 소프트웨어 인도의 핵심이다. 이를 둘러싼 위험을 제대로 관리하지 않으면 수많은 비용이 들고, 첫 번째 소프트웨어 구축 때보다 비용이 더 커지는 경우도 많다. 이 책은 이런 위험을 이해하는 데 필요한 정보를 제공하며, 나아가 이를 완화하는 전략을 설명한다.

야심 찬 목표이긴 하나, 한 권의 책에서 모든 주제를 상세히 다룰 수는 없다. 실제로 다음과 같은 독자들이 섭섭해할 수도 있다는 위험을 감수했다. 개발자는 아키텍처와 속성 주도 개발 방법, 상세한 리팩토링 같은 주제를 다루지 않아 서운할 수 있고, 테스터는 탐색적 테스트와 테스트 관리 전략에 충분한 지면을 할애하지 않아서, 운영자는 용량 계획, 데이터베이스 마이그레이션, 실환경 모니터링을 상세히 다루지 않아서 그런 감정이 들 수 있다.

이런 내용을 각각 상세하게 다루는 책은 시중에 나와 있다. 하지만 설정 관리, 자동화 테스트, 지속적 통합과 인도, 데이터 관리, 환경 관리, 출시 관리 같은 모든 활동을 함께 다루는 책이 없었다. 린(lean) 소프트웨어 개발 방법론에서 가르치는 중요한 주제 중 하나는 전체를 최적화하는 것이다. 이렇게 하려면 배포 프로세스와 그에 포함되는 모든 것을 하나로 묶어내는 전체론적인 접근법이 필요하다. 출시에 포함될 모든 변경 내용의 진행을 관리할 수 있어야만 소프트웨어 배포의 품질과 속도를 최적화하고 개선할 수 있다.

★ 이 책의 구성 ★

모든 사람이 이 책을 처음부터 끝까지 읽고 싶지는 않을 것이다. 도입부를 읽고 난 뒤 여러 가지 방법으로 공략할 수 있다. 반복적으로 읽는 것도 방법이겠지만, 처음부터 끝까지 읽기로 결심한 독자에게 너무 지루하지 않았으면 하는 바람이다.
이 책은 3개 부로 구성된다. 1부는 1장에서 4장까지로, 출시에 대한 일반적, 반복적, 위험 감소 이론을 다루며 이를 지원하는 실천법을 소개한다. 2부는 5장에서 10장까지로, 배포 파이프라인을 설명한다. 3부가 시작되는 11장부터는 지속적 인도를 지원하는 생태계를 다룬다.
누구든 1장은 읽기를 권한다. 경험 있는 개발자라도 소프트웨어 출시 프로세스가 생소한 경우라면 전문 소프트웨어 개발이 의미하는 바에 대한 다양한 도전과제를 발견할 수 있다. 책의 나머지 부분은 여유가 있거나 혼란스러운 상황일 때 자세히 살펴보면 된다.

1부: 기초
1부는 배포 파이프라인을 이해하는 데 필요한 선행지식을 설명한다. 각 장은 마지막 내용에 기반을 두고 있다.

1장, 소프트웨어 인도의 문제점: 여러 개발 팀에서 공통적으로 관찰되는 안티패턴을 설명하는 것으로 시작해, 목표를 달성하는 방법을 설명하는 부분으로 나아간다. 그리고 이 책의 나머지 부분에서 다루는 소프트웨어 인도의 이론을 정립하면서 마무리한다.

2장, 설정 관리: 소스 코드부터 환경과 애플리케이션 설정 빌드 스크립트에 이르기까지 빌드, 배포, 테스트, 애플리케이션 출시를 관리하는 모든 설정법을 다룬다.

3장, 지속적 통합: 애플리케이션의 모든 변경에 대해 자동화 테스트를 구축하고 수행해 소프트웨어가 언제나 동작하는 상태로 유지되게 하는 실천법을 다룬다.

4장, 테스트 전략의 적용: 모든 프로젝트의 중요 부분인 다양한 종류의 수동 테스트와 자동화 테스트 방법을 소개하고, 각자의 프로젝트에 적합한 전략을 선택하는 방법을 설명한다.

2부: 배포 파이프라인
2부에서는 파이프라인의 각 단계를 구현하는 방법을 포함해 배포 파이프라인을 자세히 다룬다.

5장, 배포 파이프라인의 구조: 이 책의 핵심이라 할 수 있는, 출시에 체크인되는 모든 변경을 관리하는 자동화 프로세스 패턴을 다룬다. 그리고 팀과 조직 수준에서 파이프라인을 적용하는 방법도 설명한다.

6장, 빌드와 배포 스크립트 작성: 자동 빌드와 배포 프로세스에 사용하는 스크립트 기술을 다루며, 이에 최적화된 실천법을 설명한다.

7장, 커밋 단계: 파이프라인의 첫 번째 단계로서 모든 변경사항이 애플리케이션에 적용되면서 수행되는 일련의 자동화 프로세스에 대해 다룬다.

8장, 자동화 인수 테스트: 자동화 인수 테스트에 대한 분석부터 구현까지 설명한다. 지속적 인도에서 인수 테스트가 중요한 이유를 설명하고, 애플리케이션의 중요 기능을 보호하는 비용 효과적인 인수 테스트 스위트를 만드는 법을 다룬다.

9장, 비기능 요구사항 테스트: 용량 테스트 중심으로 비기능 요구사항을 다룬다. 용량 테스트를 생성하는 방법과 용량 테스트 환경을 구축하는 방법을 설명한다.

10장, 애플리케이션 배포와 출시: 자동화 테스트 이후에 어떤 일이 발생하는지를 다룬다. 버튼을 눌러 출시 후보를 수동 테스트 환경, UAT, 스테이징, 최종 출시 단계로 진출시키는 데 필요한 핵심 주제인 지속적 배포, 롤백, 멈춤 없는 출시에 대해 다룬다.

3부: 제품 인도 생태계
3부에서는 배포 파이프라인을 지원하는 여러 분야를 교차하는 실천법과 기법을 설명한다.

11장, 인프라와 환경 관리: 가상화와 클라우드 컴퓨팅을 포함해 환경의 생성, 관리, 모니터링을 다룬다.

12장, 데이터 관리: 테스트와 실제 데이터를 애플리케이션의 생명주기에 따라 생성하고 변경하는 방법을 보여준다.

13장, 컴포넌트와 의존성 관리: 브랜치를 만들지 않고도 애플리케이션을 항상 출시 가능한 상태로 유지하는 방법을 설명하면서 시작한다. 그 다음, 컴포넌트 집합으로 애플리케이션을 구성하는 방법과, 이들의 구축과 테스트를 관리하는 방법을 설명한다.

14장 고급 버전 관리: 유명한 도구들을 소개하고, 버전 관리를 사용하는 다양한 패턴을 상세하게 설명한다.

15장 지속적 제품 인도 관리: 위험 관리와 규정에 대한 접근법을 설명하고 설정과 출시 관리의 성숙도 모델을 제공한다. 이와 함께 비즈니스에서 지속적인 인도의 중요성과 점진적으로 인도하는 반복적인 프로젝트의 생명주기를 설명한다.

★ 옮긴이의 말 ★

상황 1
“서비스 긴급 배포 좀 해주세요!”
“담당자가 휴가라 불가능해요.”

상황 2
“서버 한 대만 설정이 잘못되어 장애가 발생했어요.”

상황 3
“소스 코드가 빌드조차 안 되는 상태로 오래 방치되고 있어요.”

상황 4
“서비스 장애가 발생했는데 이전 버전으로 복구할 수 있나요?”
“불가능해요. 개발자가 서비스 환경에서 디버깅 중이니 기다려주세요.”

상황 5
“성능 테스트 결과가 왜 이렇게 안 맞는 건가요?”
“테스트 환경과 실 서비스 환경이 달라서 그렇습니다.”

소프트웨어 개발에 참여해본 독자라면 위에서 열거한 상황 중 적어도 한 가지 이상은 겪어봤을 것이며, 어쩌면 이 문제들을 모두 겪은 독자는 더 많을 것이다. 좋은 기획 내용을 개발자가 코드로 생산하고 QA가 테스트하고 운영자가 배포하면 소프트웨어 개발이 끝난다고 쉽게 생각할 수 있지만, 이 과정이 원활하게 동작하려면 많은 노력이 필요하다. 특히, 이러한 작업을 개인에게 의지해 수동으로 진행하는 경우라면 문제 발생을 피할 수 없다. 여러 대의 서버를 수동으로 설정하다 실수를 해서 장애가 발생하고, 수동으로 모든 테스트를 수행하느라 오랜 시간이 걸리고, 여러 개발자가 개발한 코드를 통합하는 과정에서 무수한 오류가 쏟아져 나와 많은 비용 낭비와 시간 지연이 발생한다. 나 또한 이러한 문제로 많은 어려움을 겪었으며, 이를 극복하기 위해 오랜 시간 노력해왔다.

소프트웨어 개발에서 뛰어난 아이디어를 구현해 고객이 사용할 수 있게 되는 데까지 걸리는 시간을 순환 시간(cycle time)이라 정의한다. 순환 시간이 짧으면 고객은 최신의 기능을 자주 접할 수 있으며 개발사는 고객의 반응을 살피고 적합한 소프트웨어를 개발할 수 있는 확률이 높아진다. 순환 시간을 줄이려면 소프트웨어를 고객에게 전달하는 데 필요한 개발, 테스트, 빌드, 배포, 출시 등의 단계를 효과적으로 수행해야 하며, 전체 프로세스가 효율적으로 관리돼야 한다.

이 책은 이에 필요한 기술과 사례를 다룬다. 독자는 효과적인 소프트웨어 개발에 필요한 여러 기법과 실천 방법을 배울 수 있으며, 적용 사례를 이용해 각 상황에 적합한 해결책을 도출해낼 수 있다. 그런 의미에서 이 책을 독자에게 소개할 수 있는 기회가 주어진 것에 매우 감사한 마음이다. 이 책을 활용해 효과적인 소프트웨어 개발과 출시를 수행하여 개인의 휴식과 발전을 위한 시간을 할애할 수 있는 분이 많아지길 희망한다.
대표 역자 유석문

마틴 파울러(소프트웨어 개발자)
90년대 후반 켄트 벡과 함께 스위스에서 보험 회사를 위한 작업을 수행했다. 켄트 벡이 프로젝트를 소개할 때 고도로 훈련된 팀이 매일 밤 소프트웨어를 실환경에 배포하는 점이 흥미로웠다. 정기적인 배포는 여러 이점이 있었다. 작성한 소프트웨어를 배포 시까지 기다릴 필요가 없고, 문제와 기회에 빨리 응답할 수 있으며, 빠른 작업 전환 덕에 비즈니스 고객, 최종 고객과 긴밀한 관계를 구축할 수 있었다.

지난 십 년간 소트웍스(ThoughtWorks)에 근무하며 해온 프로젝트의 공통 주제는 아이디어를 사용할 수 있는 소프트웨어로 만드는 데 걸리는 주기를 줄이는 것이었다. 많은 프로젝트를 살펴봤고 거의 대부분 주기를 단축했다. 일반적으로 매일 제품을 배포하진 않지만 팀은 보편적으로 격주 출시를 수행한다.

데이브와 제즈는 이런 변화를 일으키는 일원으로, 신뢰할 수 있는 소프트웨어를 자주 배포하는 문화를 구축하는 프로젝트에 적극 참여했다. 그들은 동료들과 함께 일 년에 한 번 배포하며 문제점을 겪는 상황에서 출시가 일상적인 일이 되도록 조직을 변화시켰다.
적어도 개발 팀에게 이 방법의 기본은 지속적 통합(CI, Continuous Integration)이다. CI는 전체 팀의 동기화를 유지하고 통합 문제로 인한 지연을 제거한다. 몇 년 전 폴 듀발(Paul Duvall)이 이 시리즈의 CI 책을 저술했다. 하지만 CI는 첫 단계다. 소프트웨어가 완전하게 메인라인에 통합됐더라도 실환경에서 수행되지 않고 있다면 소프트웨어라고 말할 수 없다. 데이브와 제즈는 그들의 책에서 ‘최후의 길’을 다루기 위해 CI로부터 이야기를 선택해 통합 코드를 실환경 소프트웨어로 만드는 배포 파이프라인을 어떻게 구축하는지를 설명한다.

이런 식의 배포에 대한 생각은 오랫동안 소프트웨어 개발의 잊혀진 구석이었으며, 개발과 운영 팀 사이의 공간에 놓여 있었다. 그러므로 이 책에서 이런 팀이 함께 작업하는 초기 선구자 역할을 하여 개발과 운영 활동으로 발전하는 기술이 나오는 것은 당연한 일이다. 또한 이 프로세스는 테스터를 포함하며, 테스트는 오류 없는 출시를 보장하는 핵심 요소다. 이런 종류의 모든 고수준의 자동화를 묶어 빠르고 오류 없이 작업을 완료할 수 있다.

이런 모든 작업엔 노력이 필요하지만 효과는 확실하다. 오래 걸리고 높은 집중도가 필요한 출시는 과거의 일이 되었다. 소프트웨어 고객은 아이디어가 매일 사용할 수 있는 동작하는 코드로 변화하는 모습을 목격하게 된다. 가장 중요한 부분은 소프트웨어 개발의 가장 해로운 스트레스 원천을 제거할 수 있다는 점이다. 누구도 월요일 새벽까지 시스템 업그레이드 출시 준비로 주말을 보내고 싶진 않을 테니 말이다.

이 책은 소프트웨어를 자주 일상적인 스트레스 없이 배포하는 방법을 보여주므로 읽기 용이할 것이다. 여러분의 팀을 위해 이에 동의할 수 있기를 바란다.

롭 산하임(Rob Sanheim)(렐러번스(Relevance) 주식회사 의장)
지속적 인도는 최신의 모든 소프트웨어 팀에게 지속적 통합의 논리적 다음 단계입니다. 이 책의 야심 찬 목표는 고객에게 지속적으로 가치 있는 소프트웨어를 제공하는 것으로, 명확하고 효과적인 이론과 실천을 통해 이를 성취할 수 있게 만듭니다.

사라 에드리(Sarah Edrie)(하버드 비즈니스 스쿨의 품질 공학 관리자)
소프트웨어 배포와 관련된 업무를 하는 사람이라면 누구나 이 책을 집어들어 아무 장이나 펼쳐 빠르게 가치 있는 정보를 얻을 수 있고, 책을 차근차근 읽어가며 조직에 적합한 배포 프로세스를 구축할 수 있으리라 믿습니다. 이 책은 소프트웨어의 구축, 배포, 테스트, 출시에 꼭 필요한 참고서라고 생각합니다.

데이먼 에드워즈(Damon Edwards)(DTO 솔루션 대표이자, dev2ops.org 공동 편집자)
소프트웨어 기반의 서비스를 구축하고 인도하는 비즈니스를 운영 중이라면 지속적 인도에서 명료하게 설명하는 핵심을 경험할 수 있습니다. 험블과 팔리는 이론을 넘어 제품 인도를 빠르고 신뢰할 수 있도록 변화시킬 멋진 각본을 제공합니다.

존 올스포(John Allspaw)(잇시닷컴(Etsy.com)의 기술 운영 부사장이자, 『The Art of Capacity Planning』과 『Web Operations』 저)
무엇이 빠르게 성장하는 웹 애플리케이션을 성공적으로 만드는지를 설명하고 있는 책입니다. 지속적 배포와 제품 인도는 논란거리를 벗어나 필수 요소가 됐으며, 이 책은 그 내용을 훌륭하게 다룹니다. 지속적 배포는 여러 수준에서 개발과 운영의 접점에 있으며, 저자들은 이를 성공적으로 다뤘습니다.

레이나 코트란(Leyna Cotran)(캘리포니아 대학교 어바인 캠퍼스 소프트웨어 연구소)
명확하고, 정확하게 잘 작성된 책으로 출시 프로세스에 무엇이 필요한지에 대한 아이디어를 독자에게 제공해줍니다. 저자는 소프트웨어 배포의 단계별 기대치와 장애물을 설명합니다. 모든 소프트웨어 엔지니어의 서재에 꼭 꽂혀 있어야 할 책입니다.

제임스 턴불(James Turnbull)(『Pulling Strings with Puppet』 저자)
많은 조직에서 지속적 인도는 단순한 배포 방법론이 아니며, 비즈니스를 수행하는 데 필수적인 요소입니다. 여러분의 환경에서 실제로 효과적인 지속적 인도를 구축하는 방법을 책에 소개했습니다.

리사 크리스핀(Lisa Crispin)(『Agile Testing』 공저자)
소프트웨어 개발 팀에 소스 코드 관리가 필수적인 것처럼 지속적 통합의 이해 여부와 상관없이 이 책은 필독서입니다. 전체 개발과 배포 프로세스를 한 번에 다루는 유일한 책이며, 기술과 도구뿐만 아니라 철학과 이론을 제공합니다. 저자는 테스트 자동화에서 자동화 배포에 이르기까지 폭넓은 독자를 위한 주제를 다룹니다. 개발 팀에 속한 프로그래머, 테스터, 시스템 관리자, DBA, 관리자 모두가 이 책을 읽어야 합니다.

켄트 벡(Kent Beck)(쓰리 리버스 인스티튜트(Three Rivers Institute))
좀 더 자주 소프트웨어를 배포하고 싶다면 이 책은 당신을 위한 것입니다. 지속적 제품 인도를 적용함으로써 위험을 감소하고 지겨운 작업을 제거하고 신뢰감을 향상시킬 수 있습니다. 저는 현재 진행 중인 모든 프로젝트에 이 이론과 실천법을 적용하고 있습니다.

1부 기반
___1장 소프트웨어 인도의 문제점
______개요
______대표적인 배포 안티패턴
______목적을 이루기 위한 방법
______효과
______출시 후보
______소프트웨어 인도의 원칙
______정리

___2장 설정 관리
______개요
______버전 관리 이용
______의존성 관리
______소프트웨어 설정 관리
______환경 관리
______정리

___3장 지속적 통합
______개요
______지속적 통합 적용
______지속적 통합의 전제 조건
______지속적 통합 소프트웨어 사용
______필수 실천 항목
______추천 실천법
______분산 팀
______분산 버전 관리 시스템
______정리

___4장 테스트 전략의 적용
______개요
______테스트 종류
______실제 상황과 전략
______프로세스
______정리

2부 배포 파이프라인
___5장 배포 파이프라인의 구조
______개요
______배포 파이프라인이란?
______배포 파이프라인 실천법
______커밋 단계
______자동화 인수 테스트 관문
______후속 테스트 단계
______출시 준비
______배포 파이프라인 구현
______지표
______정리

___6장 빌드와 배포 스크립트 작성
______개요
______빌드 도구의 개요
______빌드와 배포 스크립트 작성의 원칙과 실제
______JVM을 대상으로 한 애플리케이션의 프로젝트 구조
______배포 스크립트 작성
______팁과 유용한 정보
______정리

___7장 커밋 단계
______개요
______커밋 단계의 이론과 실제
______커밋 단계의 결과
______커밋 테스트 스위트의 원칙과 관행
______정리

___8장 자동화 인수 테스트
______소개
______자동화 인수 테스트가 필수인 이유
______인수 테스트 생성
______애플리케이션 드라이버 계층
______인수 테스트 구현
______인수 테스트 단계
______인수 테스트 성능
______정리

___9장 비기능 요구사항 테스트
______개요
______비기능 요구사항 관리
______용량을 고려한 프로그래밍
______용량 측정
______용량 테스트 환경
______자동화 용량 테스트
______배포 파이프라인에 용량 테스트 추가
______용량 테스트 시스템의 추가적인 이득
______정리

___10장 애플리케이션 배포와 출시
______개요
______출시 전략 수립
______애플리케이션 배포와 홍보
______배포 롤백과 무정지 출시
______긴급 수정
______지속적 배포
______팁과 트릭
______정리

3부 제품 인도 생태계
___11장 인프라와 환경 관리
______개요
______운영 팀의 요구 이해하기
______인프라의 모델링과 관리
______서버 공급과 설정 관리
______미들웨어 설정 관리
______인프라 서비스 관리
______가상화
______클라우드 컴퓨팅
______인프라와 애플리케이션 모니터링
______정리

___12장 데이터 관리
______개요
______데이터베이스 스크립트 작성
______점진적 변경
______데이터베이스 롤백 수행 및 무정지 출시
______테스트 데이터 관리
______데이터 관리와 배포 파이프라인
______정리

___13장 컴포넌트와 의존성 관리
______개요
______애플리케이션을 출시 가능하게 유지
______의존성
______컴포넌트
______의존성 그래프 관리
______바이너리 관리
______메이븐을 이용한 의존성 관리
______정리

___14장 고급 버전 관리
______개요
______간략히 살펴보는 리비전 관리의 역사
______브랜치 나누기와 병합
______분산 버전 관리 시스템
______스트림 기반 버전 관리 시스템
______메인라인에서 개발
______출시 브랜치 나누기
______기능 기반 브랜치
______팀 기반 브랜치
______정리

___15장 지속적 제품 인도 관리
______개요
______설정과 출시 관리를 위한 성숙도 모델
______프로젝트 생명주기
______위험 관리 프로세스
______흔한 제품 인도의 문제: 증상과 이유
______준수와 감사
______정리

★ 저자 서문 ★

어제 당신의 상관이 시스템의 대단한 신 기능을 고객에게 시연하라 요구했지만 아무것도 보여줄 수 없었을 것이다. 모든 개발자가 신규 기능을 개발하고 있지만 애플리케이션을 당장 실행할 수 있는 사람은 없다. 코드를 컴파일하고 지속적 통합 서버에서 모든 단위 테스트를 통과했지만 외부에서 접근할 수 있는 UAT 환경에 신규 버전을 출시하는 데 며칠이 걸린다. 그처럼 짧은 시간에 알려주고 시연을 요구하는 건 불합리한 일일까?

제품에 심각한 오류가 있다. 매일 비즈니스에서 손실이 발생하고 있다. 무엇을 수정해야 하는지 알고 있다. 세 단계 계층 시스템에서 모두 사용하는 라이브러리 하나와 그에 대응하는 데이터베이스를 수정하면 된다. 하지만 지난번 소프트웨어 신 버전을 실환경에 출시하느라 주말 새벽 3시까지 작업을 해야 했고 그 일 직후 배포를 담당했던 직원이 사직해버렸다. 다음번 출시는 주말을 넘겨 작업하게 되리란 사실을 알고 있으며, 이는 근무 시간에 애플리케이션이 동작하지 않을 것이란 의미다.

모두 공통의 문제이긴 하지만 이 문제들은 소프트웨어 개발 프로세스에서 피할 수 없는 결과가 아니다. 이건 뭔가 잘못되고 있다는 신호다. 소프트웨어 출시는 매우 빠르고 반복 가능한 프로세스여야 한다. 요즘 많은 회사가 하루에 수차례 출시를 수행한다. 심지어 코드 기반이 매우 복잡한 대규모 프로젝트에서도 가능하다. 이 책에서 이를 수행하는 방법을 보여준다.

“당신의 조직은 한 줄의 코드를 수정해 배포하는 데 얼마나 걸립니까? 배포 방법은 반복적이고 신뢰할 수 있습니까?”라고 메리와 톰 포펜딕은 질문한다. 변경하기로 마음 먹는 것에서 실제 적용까지 걸리는 시간을 순환 시간(cycle time)이라 하며, 프로젝트의 중요한 지표다.
많은 조직의 순환 시간을 측정해보면 수 주나 수개월이며 배포 프로세스는 전혀 반복적이지 않거나 신뢰할 수 없다. 수동으로 처리하고 때론 실환경 배포뿐만 아니라 테스트나 스테이징 환경에 소프트웨어를 배포하는 경우에도 한 팀의 사람이 필요하다. 이와 유사한 복잡한 프로젝트 환경에서 시작한 경우라도 집중적인 개량을 통해 중요한 수정사항의 경우 팀의 순환 시간을 수 시간 또는 수 분으로 단축했다. 이것이 가능했던 이유는 빌드, 배포, 테스트, 출시 프로세스의 여러 단계를 변경해 완전히 자동화하고, 반복적이고, 신뢰할 수 있는 프로세스를 구축했기 때문이다. 자동화가 핵심이다. 개발자, 테스터, 운영자가 소프트웨어의 생성과 배포에 관련한 공통 작업을 버튼 하나를 눌러 수행할 수 있다.

이 책은 아이디어에서 비즈니스 가치를 실현하는 순환 시간을 짧고 안전하게 하여 소프트웨어 출시를 혁신화하는 방법을 다룬다.
소프트웨어를 고객에게 인도하지 못하면 수익을 창출하지 못한다. 이것이 명백한 사실임에도 대부분의 조직이 소프트웨어를 실환경에 출시하는 작업을 주로 수동으로, 에러가 발생하기 쉬운 위험한 프로세스로 처리한다. 순환 시간을 측정해보면 수개월인 경우가 보통이며, 이보다 긴 회사도 많다. 출시 주기가 1년보다 긴 경우도 있다. 큰 규모의 회사에서 아이디어를 제품으로 구현하는 데 가장 긴 순환 주기가 아닌 일주일의 지연이라도 발생하면 수백만 불의 기회 비용이 발생한다.
이런 상황임에도 위험도가 낮은 소프트웨어 출시를 가능하게 만드는 프로세스와 메커니즘이 최신 소프트웨어 개발 프로젝트의 중요한 부분으로 취급받지 못하고 있다.
우리의 목적은 소프트웨어를 개발자로부터 실환경으로 인도하는 배포 과정을 신뢰할 수 있고, 예측 가능하며, 가시화된 그리고 잘 이해된 대규모 자동화 프로세스로 위험을 정량화할 수 있게 만드는 것이다. 이 책에서 설명하는 접근법을 이용하면 수 분 또는 수 시간 안에 아이디어를 동작하는 코드로 만들어 실환경에 배포하는 동시에 배포할 소프트웨어의 품질을 개선할 수 있다.
성공적인 소프트웨어 배포와 관련된 중요 비용은 첫 번째 출시 후 발생한다. 이 비용은 지원, 유지 보수, 신 기능 추가, 오류 수정 비용이다. 특히, 소프트웨어의 첫 번째 출시에선 사용자에게 가치를 제공하는 최소한의 기능만 포함하는 반복적인 프로세스를 이용하는 경우 그렇다. 그러므로 이 책의 원서 제목인 ‘Continuous Delivery’는 애자일 선언의 첫 번째 원칙인 ‘최상위의 목적은 빠르고 지속적으로 가치 있는 소프트웨어를 인도함으로써 고객을 만족시키는 것이다.’ [bibNp0]라는 개념을 대표한다. 성공적인 소프트웨어는 첫 번째 출시가 배포 프로세스의 시작이라는 실제 상황을 반영한다.

이 책에서 다루는 모든 기술은 사용자에게 새로운 버전의 소프트웨어 인도와 관련된 시간과 위험을 줄여준다. 피드백을 증가시키고 제품 인도와 관련된 개발자, 테스터, 운영자 간의 협업을 개선함으로써 이를 달성한다. 이 기술들은 오류 수정이든 신규 기능 인도 상황이든 간에, 애플리케이션 변경 시 내용을 수정한 다음 결과를 배포해 사용하는 데 걸리는 시간을 가능한 한 줄여주고, 발생하는 문제는 수정이 용이한 가능한 한 빠른 시점에 발견해 관련된 위험을 잘 파악할 수 있게 해준다.