• 지속적인 통합
  • 소프트웨어 품질을 높이고 위험을 줄이기

  • 폴 M. 듀발, 스티븐 M. 마티야스, 앤드류 글로버 지음
  • 최재훈 옮김

  • IT Leaders 시리즈 _ 005
  • ISBN: 9788992939133
  • 22,000원 | 2008년 03월 27일 발행 | 324쪽



졸트 상 수상에 빛나는 「지속적인 통합」

많은 개발자들이, 수많은 소프트웨어 컴포넌트를 꾸역꾸역 기워 맞추느라 며칠씩 '통합 지옥'을 헤매는 경험을 합니다. 『지속적인 통합: 소프트웨어 품질을 개선하고 위험을 줄이기』는 통합을 필요악이 아닌 일상적인 개발 프로세스의 일부로 바꿀 수 있는 방법을 설명합니다. 저자들이 말하듯, 핵심은 지속적인 통합(Continuous Integration, CI) 실천 방법과 기법을 이용하여 통합을 자주, 그리고 규칙적으로 하는 겁니다.

저자들은 먼저 지속적인 통합의 개념과 그 실천 방법을 기초에서부터 검토하고, 그러고 나서 CI 시스템이 수행하는 데이터베이스 통합, 테스트, 검사, 배포, 피드백 같은 효과적인 프로세스들을 다룹니다. 다양한 언어로 작성된 40여 개의 CI 관련 적용 사례를 통해, 독자들은 지속적인 통합으로 보다 신속하게 소프트웨어를 개발하고, 개발 생명주기의 매 단계마다 배포할 수 있는 소프트웨어를 생산하며, 결함이 발생한 시점과 발견한 시점의 간격을 좁혀주어, 시간을 아끼고 비용을 절감시켜준다는 걸 배우게 됩니다. 지속적인 통합을 제대로 실천한다면, 개발자들은 되풀이되는 수작업과 그로 인한 위험을 줄이고, 팀은 더 나은 프로젝트 가시성을 확보하게 됩니다.

이 책에서 다루는 내용은 다음과 같습니다.

  • 소프트웨어 개발 프로젝트에서 통합을 특별한 일이 아닌 '별 것 아닌 일'로 만드는 방법
  • 소프트웨어를 빌드할 때 되풀이해서 수행하는 프로세스의 양을 줄이는 방법
  • 지속적인 통합을 효과적으로 활용하기 위한 팀 단위 실천 방법 및 기법
  • 뒤늦은 결함 발견, 저품질의 소프트웨어, 가시성의 부재, 배포 가능한 소프트웨어의 부재라는 위험을 줄이는 방법
  • 시장에 나와 있는 다양한 CI 서버 및 CI 관련 도구에 대한 평가

 

마틴 파울러의 추천사

소프트웨어 업계에서 근무한 지 얼마 되지 않았을 무렵엔 개별적으론 잘 동작하던 모듈도 한데 모으면, 도대체가 이해하기조차 어려운 형태로 모든 게 엉망이 되어 버 리곤 했습니다. 하지만 지난 몇 년간, 통합은 프로젝트에서 가장 고생스러운 일에서 별 것 아닌 일로 축소되었습니다.

이렇게 된 가장 근본적인 원인은 좀더 자주 통합하는 실천 방법입니다. 한때는 매 일 빌드하는 것을 야심찬 목표로 생각한 적도 있었습니다. 지금 이야기하는 대부분 의 프로젝트들은 하루에도 여러 차례 통합을 합니다. 참 이상하게도, 고생스러울수 록 좀더 자주하는 것이 상책인 듯합니다.

지속적인 통합에 있어 흥미로운 것 중 하나는 지속적인 통합이 주는 효과에 사람 들이 종종 놀란다는 겁니다. 우리는 사람들이 지속적인 통합의 효과를 별로 중요하 지 않은 이점으로 치부해버리는 모습을 발견합니다. 하지만 지속적인 통합은 프로 젝트에 완전히 다른 분위기를 불러일으킬 수 있습니다. 문제를 더 빨리 탐지해내기 때문에 가시성이 훨씬 좋아집니다. 잘못을 저지르고 그것을 발견해내는 간격이 줄 기 때문에, 뭐가 변경됐는지 쉽게 살펴볼 수 있어서 원인을 찾아내는 데 도움이 되 므로 결함을 찾아내기 더 쉽습니다. 이것이 테스트 프로그램과 결합하면, 버그를 획 기적으로 줄일 수 있습니다. 그 결과, 개발자는 디버깅하는 데 시간을 덜 쓰고 기능 을 넣는 데 시간을 더 쓰게 되며, 견고한 기초를 닦고 있다는 자신감을 갖게 됩니다. 물론, 통합을 더 자주하라고 말로만 해선 충분하지 않습니다. 이 간단한 캐치 프 레이즈 뒤에는 지속적인 통합을 현실로 만들어 주는 원칙과 실천 방법이 한 다발 있 습니다. 원칙과 실천 방법에 관한 조언들은 대부분 여러 책과 인터넷에 흩어져 있었 기 때문에 스스로 찾아서 탐구해야 했습니다.

그래서 폴이 이러한 정보들과 최고의 실천 방법들을 응집력 있는 한 권의 책으로 묶어서 이러한 책을 기다렸던 사람들에게 지침서를 만들어준 걸 보고 기뻤습니다. 간단한 실천 방법이 으레 그렇듯, 세세한 부분으로 들어가면 어려워집니다. 지난 몇 해에 걸쳐 우리는 그 같은 세부 사항에 대해 많은 것을 연구했고 어찌 대처하면 되 는지를 공부했습니다. 이 책은 지속적인 통합이 소프트웨어 개발에 탄탄한 기초를 제공하듯, 지속적인 통합을 위한 탄탄한 기초를 마련해주는 이러한 교훈들을 모아 놓았습니다.

 

베타리더후기

“폴 줄리어스의 서문에 나온 것처럼 언젠가 나도 이런 책을 쓸 수 있길 바라왔는데, 폴을 비롯한 뛰어난 실용주의자들이 그들의 지식과 경험을 한데 묶어서 이런 멋진 책을 만들었고 그 책의 한글판을 내는데 제가 조금이나마 힘을 보탰다는 사실만으로도 기분이 좋아지네요. 이 책이 국내 개발자들의 역량을 높여줄 것이라 확신합니다.” — 황상철, http://moai.tistory.com/

“마틴 파울러와 켄트 벡이 처음에 언급한 '지속적인 통합'은 XP의 실천방법 중 하나입니다. 이 책은 제목처럼 소프트웨어의 품질을 향상시키고, 위험을 줄이기 위한 방법을 하나씩 이야기하고 있습니다. 저자의 경험에서 나오는 사례들은 저 역시도 프로젝트를 진행하며 매번 느끼던 것이었으며, 해결을 위하여 항상 어려움에 빠지곤 했었습니다. 많은 인원이 투입될수록, 프로젝트의 형상 관리 유무는 소프트웨어 설계와 비견할 만큼 품질에 많은 영향을 미친다고 생각합니다. 실천을 강조하는 XP의 정신처럼, 이 책에서는 CruiseControl과 같은 다양한 tool에 대한 사용 방법도 함께 언급하고 있기에 Project에서도 곧바로 적용이 가능합니다. 변역자인 최재훈님 또한 유명 블로거답게 완벽하게 우리말로 옮겨주셨기에, 원서에서 전해오는 오롯한(?) 느낌을 충분히 이 책을 통해서도 받으실 수 있습니다. ” — 우상정, http://again4you.tistory.com

“(인간적으로는 돌아볼 일 없는 이이긴 하지만) 래리 월은 개발자의 덕목 중 하나로 '게으름'을 꼽았었죠. 이 책에서는 게으르지 못한 개발자를 '고객의 신발은 빈틈없이 고쳐주면서, 정작 자신의 아이들을 위한 신발 수선은 잊어버리는 구두 수선공'이라고 꼬집고 있던데 어쩐지 이 구절에 저자의 의도가 다 담겨 있는 듯하네요. 자, 게으르고자 하는 개발자를 위한 멋진 친구 하나를 소개합니다. 이 책으로 다른 멋진 책을 집필하는 여유 시간을 얻을 수 있는 개발자들이 늘어나길 기대하고... 음 그리고 혹시 앰비언트 오브를 제게 선물할(아니 구경시켜 줄) 이를 찾습니다.” — 김형준, http://tzara.wordpress.com

“회사에 처음 입사했을 때가 생각이 납니다. 한 달에 한 번 정도는 각자 개발한 코드를 합치는 작업을 진행했죠. 통합 작업이 시작되면 정신이 없어지기 시작합니다. 기본적인 컴파일부터 꼬이기 시작하죠. 각자 구현한 부분을 통합하는 데에만 하루 이틀 정도의 시간이 흐릅니다. 자주 이루어지지도 않고 자동화되지도 않은 이러한 통합은 고된 작업이기도 하지만, 생산적인 일에 쓰일 시간을 낭비하게 되기도 하죠. 이 책은 통합을 자주, 그리고 자동으로 하는 법에 대한 책입니다. 이론적인 설명뿐 아니라 실질적으로 툴을 다루는 법에 대한 상세한 설명도 함께 있습니다. 책에 설명된 몇몇 부분은 베타리딩을 하는 중간중간 프로젝트에 빠르게 적용해 볼 수 있었습니다. 좋은 책을 미리 읽을 수 있는 기회를 얻게 된 것이 행운이라 생각합니다. 좋은 번역서가 또 한 권 나왔으니 프로젝트의 생산성을 한 층 더 높이는 계기가 될 거라 생각합니다.” — Paromix, http://paromix.egloos.com

“말기암환자들에게는 조기검진과 정기검사의 아쉬움이 많을 것입니다. 그 둘이 잘 지켜졌다면 종양이 발견되더라도 조기에 대처하여 생명의 위협까지는 받지 않았을 것입니다. ‘지속적인통합(CI)’은 어떤 의미에선 프로젝트를 살아남게 하는 조기검진과 정기검사가 아닐까요? CI는 프로젝트의 생명성뿐만 아니라 개발자가 본연의 가치 창조업무에 집중할 수 있게 해주므로 개발자의 생명성도 보장해 줄 것입니다. 이 책은 CI의 개념과 실제 적용을 자세히 소개하고 있습니다. 국내소프트웨어 개발사에서 CI를 개발프로세스의 필수요소로 삼고자 할 때 좋은 가이드북입니다.” — 이주호 nightthunder@gmail.com

폴 M. 듀발(Paul M. Duvall)

컨설팅 회사인 Stelligent 사의 CTO이자, 소프트웨어 생산을 최적화함으로써 개발 팀이 안정적이고 신속하게 더 나은 소프트웨어를 만드는 것을 돕는 일에 있어 사고 리더이다. 금융, 주택, 정부, 보건, 그리고 큰 규모의 독립적 소프트웨어 벤더를 비롯해 다양한 산업 분야에서 고객들에게 컨설팅을 해왔으며, www.testearly.com와 www.integratebutton.com에서 열심히 블로깅을 한다.

스티븐 M. 마티야스 3세(Stephen M. Matyas III)

5AM Solutions 사의 서비스 부분인 AutomateIt의 부사장이다. 응용 소프트웨어 공학에서 다양한 경력을 가지고 있으며, 엔터프라이즈 자바와 외주 소프트웨어 및 서비스 개발에 관하여 풍부한 실무 경험을 갖추고 있다.

앤드류 글로버(Andrew Glover)

Stelligent 사의 사장이며 북미지역에서 개최되는 다양한 컨퍼런스에서 연사로 활동중이다. 여러 권의 책과 온라인 기사를 쓴 저자이자 공저자이기도 하다.

최재훈

http://kaistizen.net, kaistizen@gmail.com

게임 개발을 업으로 삼는 프로그래머이다. 게임 개발에 있어선 이제 막 반년이 지난 초보이지만, 흥미롭고 생소한 기술을 많이 접하고, 익숙하진 않지만 독특한 분위기를 누리느라 항상 즐겁다.

여전히 스타크래프트는 무한맵에서 하고, 올해에 나올 게임 기대작으론 스포어(Spore)를 손에 꼽는다. 게임 개발자답지 않게 평소엔 게임을 즐겨 하지 않지만, 기대작이 나오면 다른 일은 제쳐놓고 삼매경에 빠진다. 유머 사이트에 떠도는, '슈퍼로봇대전 OGS'의 엔딩을 보고 싶다고 적은 휴가 계획서를 보고 그 용기가 멋지다고 생각하는 사람이다.

락 밴드는 U2가 최고라 생각하고, 15년째 '배철수의 음악 캠프'를 들은 애청자이다. 『Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드』에 이어 이번이 두 번째 역서이다. 번역을 마치고 몇 번이나 검토를 해도, 여전히 고칠 부분이 많아 부끄럽다. 그저 전작 때보단 좀더 제대로 번역했다는 소리를 듣고 싶다.

 

역자 서문

아침 일찍 출근하고 컴퓨터를 켠다. 윈도우 로고가 뜨는 사이, 가방 정리를 하고 컵을 씻고 홍차를 준비한다. 그러다 윈도우 로그인 창이 뜨면 암호를 입력한다. 윈도우 바탕화면이 뜨고 웹 브라우저를 연다. 차 한 모금을 입 안에 담고, 느긋하게 RSS 구독기를 통해 어제 밤 사이에 올라온 글을 읽는다.

뭔가 이상하지 않습니까? 다시 해볼까요?

암호를 입력한다. 윈도우 바탕화면이 뜨면, IDE를 실행시키고 소스 코드를 열심히 살펴본다.

그래도 여전히 뭔가 이상한데요? 어떤 사람은 출근해서 웹툰부터 볼지도 모릅니다. 너무 오래 만화 감상에 열중하지 않는다면, 만화를 보며 긴장을 풀어도 좋겠지요. 하지만 여기서는 딱딱하게 '회사에선 일만 해라'라고 말하려는 게 아닙니다. 게임 개발사에선 '게임을 즐기는 것조차 일'이라고 하더군요. 그런 면에선 저는 직무 유기를 한다는 소리를 들어야 할지도 모르겠습니다. 그렇다면 처음 제시한 시나리오가 왜 이상하다는 걸까요? 한번만 더 해보겠습니다.

암호를 입력한다. 시작 프로그램들이 뜬다. 윈도우 작업 표시줄에 CCTray 트레이 아이콘이 뜨더니, 이내 반가운 녹색 불빛이 들어온다. '아, 오늘 아침도 프로젝트는 안녕한가 보구나'. 안심하고 마음 편히 '마음의 소리'(웹툰)을 보러 간다.

CCTray는 CruiseControl .NET이라는 빌드 자동화 서버와 통신하고, 빌드가 깨지지 않았는지, 테스트가 실패하지 않았는지 알려줍니다. 녹색 불빛은 '걱정하지 말라'는 표시입니다. 아침에 출근해서 손수 소스 코드를 빌드해보지 않아도, 프로젝트가 잘 돌아가는지 알게 해주니 참 고마운 도구입니다. 생각해보세요. 여러분은 아침에 출근하며, 전날에 밤을 샜다면 낮에 출근하며 이런 생각해본 적 없습니까? '오늘은 제발 프로그램을 띄워보기라도 하자'. 컴파일은 어떻게든 되는데, 막상 돌려보면 어찌된 영문인지 이상한 행동만 보이고, 뭐가 문제인지 알고 보면 한달 전에 겪어던 문제이고, 끝이 없습니다. 회사 갈 생각만 해도 머리가 지끈거리니 참 큰일입니다.

이 책은 두통거리를 제대로 다루는 방법에 대해 말합니다. CCTray만 봐도 안심하고 일할 수 있는 그런 환경을 만드는 법을 알려줍니다.

사실 역자 서문이란 게 그리 흥미로운 대목은 아닙니다. 독자들이 알고 싶어하는 내용은 전부 저자들이 설명해놨고, 역자가 할 일이라곤 그저 이 책이 얼마나 훌륭한지, 왜 이 책을 읽어야 하는지 간단히 설명하는 정도일 뿐이죠. 그러니 이쯤에서 마침표를 찍겠습니다. 앞서 제시한 시나리오만으로도 명석한 여러분은 이 책이 왜 쓸모 있는지, 이 책에서 무엇을 배우게 될지 알았을 겁니다.

2008년 3월 어느 날

역자 최재훈

  • 역자서문
  • 마틴 파울러의 머릿말
  • 폴 줄리어스의 머릿말
  • 서문
  •  
  • PART I 지속적 통합의 배경: 원칙과 실천 방법
  •  
  • chapter1 시작하기
    • 변경할 때마다 소프트웨어를 빌드하기
      • 개발자
      • 버전 관리 저장소
      • 지속적인 통합 서버
      • 빌드 스크립트
      • 피드백 메커니즘
      • 통합 빌드 머신
    • 지속적인 통합의 특징
      • 소스 코드 컴파일
      • 데이터베이스 통합
      • 테스트
      • 검사 (Inspection)
      • 배포
      • 문서화와 피드백
    • 요약
    • 질문
  •  
  • chapter2 지속적인 통합 도입하기
    • 지속적인 통합과 함께 하는 하루 일과
    • 지속적인 통합에는 어떤 가치가 있을까요?
      • 위험을 줄여줍니다
      • 반복적인 프로세스를 줄여줍니다
      • 배포할 수 있는 소프트웨어를 생성합니다
      • 프로젝트 가시성을 더 높입니다
      • 제품에 대해 보다 큰 자신감을 갖게 됩니다
    • 지속적인 통합을 왜 도입하지 못할까요?
    • '지속적인' 통합을 도입하려면 어떻게 해야 할까요?
    • 언제, 어떻게 프로젝트에 지속적인 통합을 도입해야 할까요?
    • 통합의 진화
    • 지속적인 통합은 다른 개발 실천 방법을 어떻게 보완할까요?
    • 지속적인 통합을 수립하려면 얼마나 걸릴까요?
    • 지속적인 통합과 나
    • 코드를 자주 커밋하세요
    • 깨진 코드를 커밋해선 안 됩니다
    • 빌드가 깨지면 즉시 고치세요
    • 자동화된 개발자 테스트를 작성하세요
    • 테스트와 검사는 모두 통과해야 합니다
    • 개인 빌드를 돌리세요
    • 깨진 코드는 가져오지 마세요
    • 요약
    • 질문
  •  
  • chapter3 지속적인 통합을 이용해 위험 줄이기
    • 위험 요소: 배포 가능한 소프트웨어의 부재
      • 시나리오: "내 컴퓨터에선 되는데요"
      • 시나리오: 데이터베이스와 동기화하기
      • 시나리오: 버튼을 안 눌렀어요
    • 위험 요소: 뒤늦은 결함 발견
      • 시나리오: 회귀 테스트
      • 시나리오: 테스트 적용범위 (Test Coverage, 테스트 커버리지)
    • 위험 요소: 프로젝트 가시성의 부재
      • 시나리오: "제가 남긴 메모 보셨나요?"
      • 시나리오: 소프트웨어를 시각화할 역량의 부재
    • 위험 요소: 저품질의 소프트웨어
      • 시나리오: 코딩 표준 준수
      • 시나리오: 설계 지침 준수
      • 시나리오: 중복 코드
    • 요약
    • 질문
  •  
  • chapter4 변경될 때마다 소프웨어를 빌드하기
    • 빌드를 자동화하기
    • 명령어 하나로 빌드를 수행하기
    • IDE에서 빌드 스크립트를 분리해내기
    • 소프트웨어 자산을 중앙 집중화하기
    • 일관성 있는 디렉터리 구조를 만들기
    • 빌드를 빨리 실패하게 만들기
    • 어떤 환경에서라도 빌드하기
    • 빌드 유형과 메커니즘
      • 빌드 유형
      • 빌드 메커니즘
      • 빌드 시작시키기
    • 전용 통합 빌드 머신을 사용하기
    • 지속적인 통합 서버를 사용하기
    • 사람이 직접 통합 빌드를 돌리기
    • 빌드 시간을 짧게 만들기
      • 빌드 메트릭 수집하기
      • 빌드 메트릭 분석하기
      • 개선 방안을 고르고 실행하기
    • 빌드를 여러 단계로 나누기
      • 다시 평가하기
    • 이런 게 과연 효과가 있을까요?
    • 요약
    • 질문
  •  
  • PART II 완전한 기능을 갖춘 지속적인 시스템 만들기
  •  
  • chapter5 지속적인 데이터베이스 통합
    • 데이터베이스 통합을 자동화하기
      • 데이터베이스 만들기
      • 데이터베이스 조작하기
      • 빌드 데이터베이스 편성 스크립트 만들기
    • 로컬 데이터베이스 샌드박스를 사용하기
    • 버전 관리 저장소를 사용해서 데이터베이스 자산을 공유하기
    • 지속적인 데이터베이스 통합
    • 개발자에게 데이터베이스를 수정할 권한을 주기
    • 팀이 다 함께 깨진 빌드를 고치는 일에 집중하기
    • DBA를 개발 팀의 일원으로 만들기
    • 데이터베이스 통합과 통합 버튼
      • 테스트
      • 검사
      • 배포
      • 피드백과 문서화
    • 요약
    • 질문
  •  
  • chapter6 지속적인 테스트
    • 단위 테스트 자동화하기
    • 컴포넌트 테스트 자동화하기
    • 시스템 테스트 자동화하기
    • 기능 테스트 자동화하기
    • 개발자 테스트를 여러 범주로 나누기
    • 시간이 덜 걸리는 테스트부터 실행하기
      • 단위 테스트
      • 컴포넌트 테스트
      • 시스템 테스트
    • 결함 검사용 테스트 작성하기
    • 컴포넌트 테스트를 반복할 수 있게 만들기
    • 테스트 케이스 하나에 어썰트(assert) 하나로 제한하기
    • 요약
    • 질문
  •  
  • chapter7 지속적인 검사
    • 검사와 테스트는 무엇이 다를까요?
    • 검사기를 얼마나 자주 돌려야 할까요?
    • 코드 메트릭: 그 역사
    • 코드 복잡도를 줄이기
    • 설계 검토를 지속적으로 수행하기
    • 코드 심사(Audit)를 하여 조직에서 정한 표준을 잘 지키게 하기
    • 중복 코드를 줄이기
      • PMD-CPD 사용하기
      • Simian 사용하기
    • 코드 적용범위를 평가하기
    • 코드 품질을 지속적으로 평가하기
      • 적용범위 테스트 수행 빈도
      • 적용범위 테스트와 성능
    • 요약
    • 질문
  •  
  • chapter8 지속적인 배포
    • 작동하는 소프트웨어를 언제, 어느 곳에서든 릴리즈하기
    • 저장소 안의 자산에 꼬리표 붙이기
    • 깨끗한 환경 만들기
    • 각 빌드에 꼬리표 붙이기
    • 테스트를 모두 돌리기
    • 빌드 피드백 보고서 만들기
    • 릴리즈를 롤백할 수 있는 능력 확보하기
    • 요약
    • 질문
  •  
  • chapter9 지속적인 피드백
    • 적절하게
      • 적절한 정보
      • 적절한 사람
      • 적절한 시기
      • 적절한 방법
    • 지속적인 피드백 메커니즘 사용하기
      • 이메일
      • SMS (문자 메시지)
      • 앰비언트 오브와 X10 디바이스
      • 윈도우 작업 표시줄
      • 소리
      • 와이드 스크린 모니터
    • 요약
    • 질문
  •  
  • epilogue 지속적인 통합의 미래
  • appendixA CI 관련 리소스
    • 지속적인 통합 도구와 제품
    • 빌드 스크립트 리소스
    • 버전 관리 리소스
    • 다른 버전 관리 리소스
    • 데이터베이스 리소스
    • 테스트 리소스
    • 자동화된 검사 리소스
    • 배포 리소스
    • 피드백 리소스
    • 문서화 리소스
  •  
  • appendixB CI 도구 평가하기
    • 도구를 평가할 때 고려할 점
      • 기능성
      • 내가 일하는 환경과의 호환성
      • 안정성
      • 수명
      • 사용자 편의성
    • 자동화된 빌드 도구
      • Ant
      • Maven 1
      • Maven 2
      • NAnt
      • Rake
    • 빌드 스케줄러 도구
      • AnthillPro
      • Continuum
      • CruiseControl
      • CruiseControl.NET
      • Draco.NET
      • Luntbuild
    • 결론
  •  
  • bibliography 참고 문헌
  • index 찾아보기