간편결제, 신용카드 청구할인
인터파크 롯데카드 5% (22,230원)
(최대할인 10만원 / 전월실적 40만원)
북피니언 롯데카드 30% (16,380원)
(최대할인 3만원 / 3만원 이상 결제)
NH쇼핑&인터파크카드 20% (18,720원)
(최대할인 4만원 / 2만원 이상 결제)
Close

성공으로 이끄는 팀 개발 실천 기술 : 효율적 협업을 위한 도구와 방법론을 말하다

원제 : チ?ム開???入門
한정판매 소득공제

2013년 9월 9일 이후 누적수치입니다.

공유하기
정가

26,000원

  • 23,400 (10%할인)

    1,300P (5%적립)

할인혜택
적립혜택
  • I-Point 적립은 마이페이지에서 직접 구매확정하신 경우만 적립 됩니다.
추가혜택
  • 6/10(토) 이내 발송 예정  (서울시 강남구 삼성로 512)
  • 무료배송
  • 주문수량
    감소 증가
    • 이벤트/기획전

    • 연관도서

    • 상품권

    AD

    책소개

    [성공으로 이끄는 팀 개발 실천 기술]은 효율적 현업을 위한 도구와 방법론을 소개한 책이다. 지속적인 개발을 실현하는 최신 개발 흐름을 살피고, 효율적 프로젝트를 지탱하기 위한 노하우를 담았다. 이 책은 서비스 및 애플리케이션을 개발하는 기업에서 팀을 이뤄 진행시켜 나가는 데 필요한 사고방식이나 사용하는 도구, 그리고 이들 도구를 제대로 사용할 수 있도록 도와준다.

    출판사 서평

    효율적 협업을 위한 도구와 방법론을 말하다!
    지속적 개선을 실현하는 최신 개발 흐름과 효율적 프로젝트를 지탱하기 위한 노하우를 배우다!


    이 책은 서비스 및 애플리케이션을 개발하는 기업에서 팀을 이뤄 개발을 진행시켜 나가는 데 필요한 사고방식이나 사용하는 도구, 그리고 이들 도구를 제대로 사용할 수 있도록 도와주고 있다. 책 도입부에서는 일이 잘 진행되지 않는 개발 현장의 일례를 보여주고 그 이유와 대책에 대해 설명한다. 그런 다음, 그 대책에 필요한 도구를 소개하고, 이어 버전 관리, 티켓 관리, CI(지속적인 통합) 배포, 회귀 테스트 등의 장을 통해 각 도구의 사용법과 함께 현장 경험이 풍부한 저자의 팀 개발 노하우를 제공하고 있다.

    이 책의 대상 독자는 다음과 같다.

    ㆍ 새롭게 개발팀을 맡게 된 신입 프로젝트 매니저
    ㆍ 새롭게 프로젝트를 시작할 예정인 프로젝트 매니저 및 스크럼 마스터
    ㆍ 기존 프로젝트에서 일정 번복이나 납기 연기 등이 빈번히 발생해서 이를 해결하기 위한 도구와 그 사용법을 알고 싶은 사람
    ㆍ ‘테스트는 테스트팀 담당이니까 관계없어’, ‘배포는 운용팀 담당이니까 관계없어’라고 생각하고 있는 사람
    ㆍ 최신 웹 서비스 개발에 도움이 되는 도구를 배우고 싶은 사람

    목차

    Chapter 1 팀 개발이란? _ 1
    1.1 혼자서도 개발할 수 있다 2
    1.2 팀 개발에서 직면하게 되는 문제 3
    1.3 문제에 어떻게 대응할까? 4
    1.4 이 책의 구성 5
    2장: 케이스 스터디 5
    3장~5장: 기초적인 방법론 5
    6장~7장: 지속적 전달과 회귀 테스트 7
    1.5 이 책을 읽기 전 주의사항 8
    최적의 방법론은 케이스 스터디 8
    어떤 도구를 사용해야 할까? 9

    Chapter 2 팀 개발에서 발생하는 문제 _ 11
    2.1 케이스 스터디 전제 12
    프로젝트 전제 조건 13
    2.2 케이스 스터디(1일째) 14
    문제 1: 중요한 메일이 너무 많아서 우선순위를 정할 수 없다 14
    문제 2: 검증용 환경이 없다 15
    문제 3: 폴더명으로 브랜치를 관리한다 15
    문제 4: 데이터베이스 재작성이 곤란 17
    2.3 케이스 스터디(1일째)의 문제점 19
    문제 1: 중요한 메일이 너무 많아서 우선순위를 정할 수 없다 19
    문제 2: 검증용 환경이 없다 21
    문제 3: 폴더명으로 브랜치를 관리한다 22
    문제 4: 데이터베이스 재작성이 곤란 23
    2.4 케이스 스터디(2일째) 26
    문제 5: 가동 전까지 고장 난 것을 알지 못하다 26
    문제 6: 다른 멤버가 수정한 것을 덮어써서 지워 버리다 27
    문제 7: 자신 있게 리팩토링할 수 없다 30
    문제 8: 버그 수정 시기를 알 수 없어서 디그레이드 추적이 되지 않는다 31
    문제 9: 브랜치 및 태그를 활용하지 못하고 있다 32
    문제 10: 테스트 환경이나 상용 환경에서는 동작하지 않는다 34
    문제 11: 배포가 복잡해서 매뉴얼이 필요하다 35
    2.5 케이스 스터디(2일째)의 문제점 36
    문제 5: 가동 전까지 고장 난 것을 알지 못하다 36
    문제 6: 다른 멤버가 수정한 것을 덮어써서 지워 버리다 37
    문제 7: 자신 있게 리팩토링할 수 없다 38
    문제 8: 버그 수정 시기를 알 수 없어서 디그레이드 추적이 되지 않는다 40
    문제 9: 브랜치 및 태그를 활용하지 못하고 있다 41
    문제 10: 테스트 환경이나 상용 환경에서는 동작하지 않는다 42
    문제 11: 배포가 복잡해서 매뉴얼이 필요하다 43
    2.6 이상적인 프로젝트란? 44
    티켓 관리 시스템에 이슈 등이 집약되어 있다 45
    가능한 버전 관리 시스템을 이용한다 46
    반복 검증 가능한 CI 시스템을 도입한다 46
    환경의 영향을 최소화하고 항상 배포 가능 상태로 둔다 47
    모두 기록해서 추적 가능하게 한다 47
    2.7 정리 48

    Chapter 3 버전 관리 _ 49
    3.1 버전 관리 시스템 50
    버전 관리 시스템이란? 50
    버전 관리 시스템을 사용하면 왜 편리한 걸까? 51
    3.2 버전 관리 시스템의 역사 60
    버전 관리 시스템이 없던 시대(1970년대 이전) 61
    RCS 시대(1980년대) 62
    CVS 등장(1990년대) 62
    VSS, Perforce 등 상용 도구 등장(1990년대) 63
    Subversion 등장(2000년대) 63
    분산 버전 관리 시스템 등장(2005년 이후) 64
    번외편: GitHub의 등장 66
    버전 관리 시스템 도입 상황 68
    3.3 분산 버전 관리 시스템 70
    분산 버전 관리 시스템을 사용해야 하는 다섯 가지 이유 70
    분산 버전 관리 시스템의 단점 71
    3.4 버전 관리 시스템 사용 방법 74
    전제 74
    버전 관리 시스템으로 관리해야 할 것 75
    3.5 Git을 사용한 효율적인 병행 개발 79
    브랜치 사용법 79
    태그 사용법 86
    3.6 Git을 사용한 개발 흐름 93
    Git을 사용한 작업 흐름 패턴 93
    브랜치 전략 패턴 96
    최적의 흐름과 브랜치 전략은 현장에 따라 다르다 101
    3.7 데이터베이스 스키마와 데이터 관리 103
    데이터베이스 스키마를 관리해야 하는 이유 103
    데이터베이스 스키마를 어떻게 관리하면 될까? 104
    데이터베이스 마이그레이션 툴 107
    기본적인 사용법(Evolution) 108
    데이터베이스 마이그레이션 주의점 115
    3.8 설정 파일 관리 116
    3.9 의존 관계 관리 118
    의존 관계 해결 시스템 118
    3.10 정리 122

    Chapter 4 티켓 관리 _ 123
    4.1 티켓 관리 시스템 124
    프로젝트가 제대로 돌아가지 않는 이유 124
    종이나 메일, 엑셀로 태스크를 관리할 시 문제점 125
    티켓 관리 시스템 도입의 장점 126
    티켓 주도 개발이란? 129
    4.2 주요 티켓 관리 시스템 131
    OSS 제품 131
    상용 제품 135
    도구 선정 포인트 140
    4.3 티켓 관리 시스템과 버전 관리 시스템의 연계 142
    연계를 통해 실현 가능한 기능 142
    연계 설정 방법 143
    GitHub 144
    Trac/Redmine 149
    Backlog 150
    Git 내장 후크 사용법 153
    4.4 신기능 개발, 버그 수정 시 작업 흐름 154
    작업 흐름 154
    4.5 ‘이 버그는 언제 수정했는가?’란 질문에 대답하기 158
    Pivotal Tracker 예 158
    Backlog 예 161
    4.6 ‘왜 이런 변경이 발생했는가?’란 의문 해결하기 164
    4.7 정리 165

    Chapter 5 CI(지속적 통합) _ 169
    5.1 CI(지속적 통합) 170
    CI(지속적 통합)란? 170
    개발을 애자일화한다 172
    왜 CI 같은 방법론이 요구되는 걸까? 175
    CI에 필요한 것 178
    테스트 코드 작성을 위한 프레임워크 180
    주요 CI 도구 184
    5.2 빌드 도구 사용법 188
    신규 프로젝트를 시작하는 경우 189
    기존 프로젝트를 자동 빌드하려면 195
    빌드 도구 정리 196
    5.3 테스트 코드 작성법 197
    CI 대상이 되는 테스트 종류 197
    테스트 코드를 언제 작성할 것인가? 198
    복잡한 테스트는 어떻게 작성할까? 200
    5.4 Jenkins를 사용한 CI 실행 205
    Jenkins 설치 205
    Jenkins로 무엇을 할 수 있나? 207
    잡 신규 작성 208
    소스 코드를 체크아웃한다 208
    자동 빌드 및 테스트 실행 210
    Column 버전 관리 시스템에서 Push한다 212
    결과를 집계해서 보고서 출력 214
    커버리지 측정 215
    정적 분석 221
    통지 설정 222
    5.5 CI 운용 224
    빌드가 망가지면 어떻게 하나? 224
    추적 가능성 확보 231
    5.6 정리 - CI를 통해 얻을 수 있는 것 237

    Chapter 6 배포 자동화(지속적 전달) _ 239
    6.1 배포는 어떻게 해야 하나? 240
    배포 자동화의 이점 241
    6.2 배포 자동화 242
    배포 자동화에 대한 공통 인식 242
    배포 파이프라인 243
    프로비저닝 툴체인 245
    6.3 부트스트랩핑 247
    Kickstart 247
    Vagrant 250
    6.4 컨피규레이션 254
    자동화를 하지 않았을 때의 문제점 254
    Chef 255
    serverspec 265
    모범 사례 1 269
    모범 사례 2 272
    물리 서버가 서비스 투입 가능한 상태가 되기까지의 흐름을 자동화한다 274
    6.5 오케스트레이션 275
    배포 작업 실패 케이스 275
    Capistrano 276
    Fabric 279
    Jenkins 283
    모범 사례 290
    보안에 대한 고려 291
    6.6 운용 시 고려해야 할 것 294
    서비스를 중단하지 않고 배포하는 방법 294
    블루-그린 배포 295
    클라우드 시대의 블루-그린 배포 298
    롤백에 대한 고찰 299
    6.7 정리 303

    Chapter 7 회귀 테스트 _ 307
    7.1 회귀 테스트 308
    회귀 테스트란? 308
    테스트 종류 정리 309
    회귀 테스트의 필요성 312
    회귀 테스트 자동화가 목표로 하는 것 314
    7.2 Selenium 316
    Selenium이란? 316
    Selenium의 이점 316
    Selenium 컴포넌트 317
    테스트 케이스 작성과 실행 322
    Selenium 실전 활용 327
    7.3 Jenkins와 Selenium 연계 334
    Jenkins와 Selenium 연계 방법 334
    7.4 Selenium 테스트 고속화 339
    Jenkins 분산 빌드로 테스트 병렬 실행 340
    Selenium 테스트 병렬화의 어려움 344
    7.5 여러 버전의 애플리케이션 테스트 348
    애플리케이션 배포 349
    테스트 케이스를 버전 관리 시스템으로부터 체크아웃 350
    Selenium에서 테스트 351
    7.6 정리 352

    참고 문헌/참고 URL 353
    찾아보기 355

    본문중에서

    다수의 인력이 문제를 공유하고 어떤 문제가 일어 났는지 알기 쉽게 공유해서, 디그레이드가 발생하지 않도록 테스트를 자동화하는 것이 중요하다. 또한, 무언가를 실수했을 때는 바로 원 상태로 복구하는 것도 중요하다. 한편, 신기능을 빠르게 개발해서 배포하지 않으면 시장 경쟁에서 밀리기 때문에 병행해서 복수의 기능을 개발해야 한다. 물론, 품질도 유지하면서 말이다.
    _4쪽

    다수의 멤버가 애플리케이션을 개발하다 보면 수정 부분이 겹쳐서 충돌이 발생하는 경우도 있다. 충돌이 발생한 경우에는 양쪽 수정이 모두 동작하도록 머지해 주어야 하지만, 이 작업이 쉽지 않다. 또한, 각 멤버가 머지를 해 줄지도 보장되지 않는다. 머지를 빼먹고 다른 사람이 수정한 것에 덮어쓰기 해도 눈치채지 못하는 경우가 있다.
    _37쪽

    데이터베이스 스키마를 버전 관리하려면 무엇을 어떻게 관리하면 되는 것일까? 구체적으로 살펴보자. 여기서는 데이터베이스로 MySQL이나 PostgreSQL 등의 RDBMS를 사용하는 경우를 전제로 해서 이야기를 진행하겠다. 단, 데이터베이스가 RDBMS가 아닌 단순 파일이나 XML 파일, 객체형 데이터베이스이거나 최근 유행하고 있는 MongoDB(몽고디비) 등의 NoSQL 데이터베이스라도 방식은 같다.
    _104쪽

    GitHub나 Backlog 같은 시스템을 사용하면 티켓 관리 시스템과 버전 관리 시스템 연계가 쉽지만, Git 자체를 수정할 수 없어서 자유도나 유연성에 한계가 있다. 앞서 언급한 시스템은 주로 Git 서버 측 후크인 Post-receive Hook를 공개하고 있을 뿐 모든 후크를 공개하고 있는 건 아니다.
    _153쪽

    이와 같이 원래는 데이터베이스 값을 테스트에 맞게 설정해야 하지만, 실제 데이터베이스는 변경하지 않고 모크 객체를 사용해서 테스트를 만들 수 있다는 것을 알 수 있다. 참고로, 코드 예제에서는 다루지 않았지만 웹 서비스 API와의 접속 부분에 대해서도 동일하게 Mockito를 사용해서 모크를 만들 수 있다. 예를 들어, 웹 서비스에 접속하는 클래스가 항상 고정 JSON 응답을 반환하도록 모크를 만들면 된다.
    _201쪽

    실제로는 복수의 커밋이 어느 정도 누적된 상태에서 브랜치가 작성되고, 이 브랜치가 상용 환경에 배포되는 흐름일 것이다. 여기서 중요한 것은 배포 파이프라인이 정체 없이 흘러가는 것이다. 각 단계가 사람에 의존한다는 이유로 배포할 수 없는 상황이 발생해서는 안 된다. 누구든지 테스트할 수 있고 배포까지 할 수 있는 것이 이상적이다.
    _245쪽

    저자소개

    후지쿠라 카즈아키, 이노우에 후미아키 [저] 신작알림 SMS신청
    생년월일 -

    해당작가에 대한 소개가 없습니다.

    김완섭 [역] 신작알림 SMS신청
    생년월일 -

    김완섭은 네덜란드 ITC에서 GIS(지리정보시스템) 연계 재난재해 관리학(석사)을 전공했다.
    약 9년간 한국 및 일본 대기업에서 다양한 IT 분야 업무를 담당했다.
    일본에서는 시스템 엔지니어로 5년간 근무했으며, 대기업 세콤(SECOM) 계열사인 파스코에서 외무성, 국토지리정보원 등 일본 정부 기관을 대상으로 한 시스템 통합(SI) 업무를 담당했다.
    이후 야후재팬으로 직장을 옮겨 야후맵 개발 담당 시니어 엔지니어로 근무하다 2010년 귀국하여 SK에서 내비게이션 데이터 담당 매니저로 근무했다.
    저서로는 《나는 도쿄 롯폰기로 출근한다》가 있으며, 역서로는 《그림으로

    펼쳐보기

    전공도서/대학교재 분야에서 많은 회원이 구매한 책

      리뷰

      0.0 (총 0건)

      100자평

      작성시 유의사항

      평점
      0/100자
      등록하기

      100자평

      0.0
      (총 0건)

      판매자정보

      • 인터파크도서에 등록된 오픈마켓 상품은 그 내용과 책임이 모두 판매자에게 있으며, 인터파크도서는 해당 상품과 내용에 대해 책임지지 않습니다.

      상호

      (주)교보문고

      대표자명

      안병현

      사업자등록번호

      102-81-11670

      연락처

      1544-1900

      전자우편주소

      callcenter@kyobobook.co.kr

      통신판매업신고번호

      01-0653

      영업소재지

      서울특별시 종로구 종로 1(종로1가,교보빌딩)

      교환/환불

      반품/교환 방법

      ‘마이페이지 > 취소/반품/교환/환불’ 에서 신청 또는 1:1 문의 게시판 및 고객센터(1577-2555)에서 신청 가능

      반품/교환가능 기간

      변심 반품의 경우 출고완료 후 6일(영업일 기준) 이내까지만 가능
      단, 상품의 결함 및 계약내용과 다를 경우 문제점 발견 후 30일 이내

      반품/교환 비용

      변심 혹은 구매착오로 인한 반품/교환은 반송료 고객 부담
      상품이나 서비스 자체의 하자로 인한 교환/반품은 반송료 판매자 부담

      반품/교환 불가 사유

      ·소비자의 책임 있는 사유로 상품 등이 손실 또는 훼손된 경우
      (단지 확인을 위한 포장 훼손은 제외)

      ·소비자의 사용, 포장 개봉에 의해 상품 등의 가치가 현저히 감소한 경우
      예) 화장품, 식품, 가전제품(악세서리 포함) 등

      ·복제가 가능한 상품 등의 포장을 훼손한 경우
      예) 음반/DVD/비디오, 소프트웨어, 만화책, 잡지, 영상 화보집

      ·시간의 경과에 의해 재판매가 곤란한 정도로 가치가 현저히 감소한 경우

      ·전자상거래 등에서의 소비자보호에 관한 법률이 정하는 소비자 청약철회 제한 내용에 해당되는 경우

      상품 품절

      공급사(출판사) 재고 사정에 의해 품절/지연될 수 있음

      소비자 피해보상
      환불지연에 따른 배상

      ·상품의 불량에 의한 교환, A/S, 환불, 품질보증 및 피해보상 등에 관한 사항은 소비자분쟁해결 기준 (공정거래위원회 고시)에 준하여 처리됨

      ·대금 환불 및 환불지연에 따른 배상금 지급 조건, 절차 등은 전자상거래 등에서의 소비자 보호에 관한 법률에 따라 처리함

      (주) 인터파크커머스 안전결제시스템 (에스크로) 안내

      (주)인터파크커머스의 모든 상품은 판매자 및 결제 수단의 구분없이 회원님들의 구매안전을 위해 안전결제 시스템을 도입하여 서비스하고 있습니다.
      결제대금 예치업 등록 : 02-006-00064 서비스 가입사실 확인

      배송안내

      • 교보문고 상품은 택배로 배송되며, 출고완료 1~2일내 상품을 받아 보실 수 있습니다.

      • 출고가능 시간이 서로 다른 상품을 함께 주문할 경우 출고가능 시간이 가장 긴 상품을 기준으로 배송됩니다.

      • 군부대, 교도소 등 특정기관은 우체국 택배만 배송가능합니다.

      • 배송비는 업체 배송비 정책에 따릅니다.

      • - 도서 구매 시 15,000원 이상 무료배송, 15,000원 미만 2,500원 - 상품별 배송비가 있는 경우, 상품별 배송비 정책 적용