책 이미지
책 정보
· 분류 : 국내도서 > 컴퓨터/모바일 > 프로그래밍 개발/방법론 > 프로그래밍 기초/개발 방법론
· ISBN : 9791185890067
· 쪽수 : 384쪽
· 출판일 : 2014-10-10
책 소개
목차
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
책속에서
다수의 인력이 문제를 공유하고 어떤 문제가 일어 났는지 알기 쉽게 공유해서, 디그레이드가 발생하지 않도록 테스트를 자동화하는 것이 중요하다. 또한, 무언가를 실수했을 때는 바로 원 상태로 복구하는 것도 중요하다. 한편, 신기능을 빠르게 개발해서 배포하지 않으면 시장 경쟁에서 밀리기 때문에 병행해서 복수의 기능을 개발해야 한다. 물론, 품질도 유지하면서 말이다.
다수의 멤버가 애플리케이션을 개발하다 보면 수정 부분이 겹쳐서 충돌이 발생하는 경우도 있다. 충돌이 발생한 경우에는 양쪽 수정이 모두 동작하도록 머지해 주어야 하지만, 이 작업이 쉽지 않다. 또한, 각 멤버가 머지를 해 줄지도 보장되지 않는다. 머지를 빼먹고 다른 사람이 수정한 것에 덮어쓰기 해도 눈치채지 못하는 경우가 있다.
데이터베이스 스키마를 버전 관리하려면 무엇을 어떻게 관리하면 되는 것일까? 구체적으로 살펴보자. 여기서는 데이터베이스로 MySQL이나 PostgreSQL 등의 RDBMS를 사용하는 경우를 전제로 해서 이야기를 진행하겠다. 단, 데이터베이스가 RDBMS가 아닌 단순 파일이나 XML 파일, 객체형 데이터베이스이거나 최근 유행하고 있는 MongoDB(몽고디비) 등의 NoSQL 데이터베이스라도 방식은 같다.
