이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능?
- 문화비소득공제 가능
이 상품의 태그
책소개
목차
|
Chapter 1 팀 개발이란?
1.1 혼자서도 개발할 수 있다 1.2 팀 개발에서 직면하게 되는 문제 1.3 문제에 어떻게 대응할까? 1.4 이 책의 구성 2장: 케이스 스터디 3장~5장: 기초적인 방법론 6장~7장: 지속적 전달과 회귀 테스트 1.5 이 책을 읽기 전 주의사항 최적의 방법론은 케이스 스터디 어떤 도구를 사용해야 할까? Chapter 2 팀 개발에서 발생하는 문제 2.1 케이스 스터디 전제 프로젝트 전제 조건 2.2 케이스 스터디(1일째) 문제 1: 중요한 메일이 너무 많아서 우선순위를 정할 수 없다 문제 2: 검증용 환경이 없다 문제 3: 폴더명으로 브랜치를 관리한다 문제 4: 데이터베이스 재작성이 곤란 2.3 케이스 스터디(1일째)의 문제점 문제 1: 중요한 메일이 너무 많아서 우선순위를 정할 수 없다 문제 2: 검증용 환경이 없다 문제 3: 폴더명으로 브랜치를 관리한다 문제 4: 데이터베이스 재작성이 곤란 2.4 케이스 스터디(2일째) 문제 5: 가동 전까지 고장 난 것을 알지 못하다 문제 6: 다른 멤버가 수정한 것을 덮어써서 지워 버리다 문제 7: 자신 있게 리팩토링할 수 없다 문제 8: 버그 수정 시기를 알 수 없어서 디그레이드 추적이 되지 않는다 문제 9: 브랜치 및 태그를 활용하지 못하고 있다 문제 10: 테스트 환경이나 상용 환경에서는 동작하지 않는다 문제 11: 배포가 복잡해서 매뉴얼이 필요하다 2.5 케이스 스터디(2일째)의 문제점 문제 5: 가동 전까지 고장 난 것을 알지 못하다 문제 6: 다른 멤버가 수정한 것을 덮어써서 지워 버리다 문제 7: 자신 있게 리팩토링할 수 없다 문제 8: 버그 수정 시기를 알 수 없어서 디그레이드 추적이 되지 않는다 문제 9: 브랜치 및 태그를 활용하지 못하고 있다 문제 10: 테스트 환경이나 상용 환경에서는 동작하지 않는다 문제 11: 배포가 복잡해서 매뉴얼이 필요하다 2.6 이상적인 프로젝트란? 티켓 관리 시스템에 이슈 등이 집약되어 있다 가능한 버전 관리 시스템을 이용한다 반복 검증 가능한 CI 시스템을 도입한다 환경의 영향을 최소화하고 항상 배포 가능 상태로 둔다 모두 기록해서 추적 가능하게 한다 2.7 정리 Chapter 3 버전 관리 3.1 버전 관리 시스템 버전 관리 시스템이란? 버전 관리 시스템을 사용하면 왜 편리한 걸까? 3.2 버전 관리 시스템의 역사 버전 관리 시스템이 없던 시대(1970년대 이전) RCS 시대(1980년대) CVS 등장(1990년대) VSS, Perforce 등 상용 도구 등장(1990년대) Subversion 등장(2000년대) 분산 버전 관리 시스템 등장(2005년 이후) 번외편: GitHub의 등장 버전 관리 시스템 도입 상황 3.3 분산 버전 관리 시스템 분산 버전 관리 시스템을 사용해야 하는 다섯 가지 이유 분산 버전 관리 시스템의 단점 3.4 버전 관리 시스템 사용 방법 전제 버전 관리 시스템으로 관리해야 할 것 3.5 Git을 사용한 효율적인 병행 개발 브랜치 사용법 태그 사용법 3.6 Git을 사용한 개발 흐름 Git을 사용한 작업 흐름 패턴 브랜치 전략 패턴 최적의 흐름과 브랜치 전략은 현장에 따라 다르다 3.7 데이터베이스 스키마와 데이터 관리 데이터베이스 스키마를 관리해야 하는 이유 데이터베이스 스키마를 어떻게 관리하면 될까? 데이터베이스 마이그레이션 툴 기본적인 사용법(Evolution) 데이터베이스 마이그레이션 주의점 3.8 설정 파일 관리 3.9 의존 관계 관리 의존 관계 해결 시스템 3.10 정리 Chapter 4 티켓 관리 4.1 티켓 관리 시스템 프로젝트가 제대로 돌아가지 않는 이유 종이나 메일, 엑셀로 태스크를 관리할 시 문제점 티켓 관리 시스템 도입의 장점 티켓 주도 개발이란? 4.2 주요 티켓 관리 시스템 OSS 제품 상용 제품 도구 선정 포인트 4.3 티켓 관리 시스템과 버전 관리 시스템의 연계 연계를 통해 실현 가능한 기능 연계 설정 방법 GitHub Trac/Redmine Backlog Git 내장 후크 사용법 4.4 신기능 개발, 버그 수정 시 작업 흐름 작업 흐름 4.5 ‘이 버그는 언제 수정했는가?’란 질문에 대답하기 Pivotal Tracker 예 Backlog 예 4.6 ‘왜 이런 변경이 발생했는가?’란 의문 해결하기 4.7 정리 Chapter 5 CI(지속적 통합) 5.1 CI(지속적 통합) CI(지속적 통합)란? 개발을 애자일화한다 왜 CI 같은 방법론이 요구되는 걸까? CI에 필요한 것 테스트 코드 작성을 위한 프레임워크 주요 CI 도구 5.2 빌드 도구 사용법 신규 프로젝트를 시작하는 경우 기존 프로젝트를 자동 빌드하려면 빌드 도구 정리 5.3 테스트 코드 작성법 CI 대상이 되는 테스트 종류 테스트 코드를 언제 작성할 것인가? 복잡한 테스트는 어떻게 작성할까? 5.4 Jenkins를 사용한 CI 실행 Jenkins 설치 Jenkins로 무엇을 할 수 있나? 잡 신규 작성 소스 코드를 체크아웃한다 자동 빌드 및 테스트 실행 Column 버전 관리 시스템에서 Push한다 결과를 집계해서 보고서 출력 커버리지 측정 정적 분석 통지 설정 5.5 CI 운용 빌드가 망가지면 어떻게 하나? 추적 가능성 확보 5.6 정리 - CI를 통해 얻을 수 있는 것 Chapter 6 배포 자동화(지속적 전달) 6.1 배포는 어떻게 해야 하나? 배포 자동화의 이점 6.2 배포 자동화 배포 자동화에 대한 공통 인식 배포 파이프라인 프로비저닝 툴체인 6.3 부트스트랩핑 Kickstart Vagrant 6.4 컨피규레이션 자동화를 하지 않았을 때의 문제점 Chef serverspec 모범 사례 1 모범 사례 2 물리 서버가 서비스 투입 가능한 상태가 되기까지의 흐름을 자동화한다 6.5 오케스트레이션 배포 작업 실패 케이스 Capistrano Fabric Jenkins 모범 사례 보안에 대한 고려 6.6 운용 시 고려해야 할 것 서비스를 중단하지 않고 배포하는 방법 블루-그린 배포 클라우드 시대의 블루-그린 배포 롤백에 대한 고찰 6.7 정리 Chapter 7 회귀 테스트 7.1 회귀 테스트 회귀 테스트란? 테스트 종류 정리 회귀 테스트의 필요성 회귀 테스트 자동화가 목표로 하는 것 7.2 Selenium Selenium이란? Selenium의 이점 Selenium 컴포넌트 테스트 케이스 작성과 실행 Selenium 실전 활용 7.3 Jenkins와 Selenium 연계 Jenkins와 Selenium 연계 방법 7.4 Selenium 테스트 고속화 Jenkins 분산 빌드로 테스트 병렬 실행 Selenium 테스트 병렬화의 어려움 7.5 여러 버전의 애플리케이션 테스트 애플리케이션 배포 테스트 케이스를 버전 관리 시스템으로부터 체크아웃 Selenium에서 테스트 7.6 정리 참고 문헌/참고 URL 찾아보기 |
저자 소개
저자 : 이케다 타카후미
대학교 졸업 후 IT 컨설턴트로 일하다 프로그래머로 전직하여 패키지 소프트웨어 및 웹 서비스를 개발하였고, 2013년부터 주식회사 DNA에서 소프트웨어 개발자로 근무하고 있다. 수년간 여러 현장을 거쳤으며, 2장의 케이스 스터디 내용 대부분은 실제 경험에 근거하여 집필했다. 자바 웹 애플리케이션 프레임워크인 Play Framework의 커미터이기도 하다. 1장~5장의 집필과 전체 감수를 담당했다.
저자 : 후지쿠라 카즈아키
대학교 졸업 후 지금까지 주식회사 캐논에서 인프라 구조 엔지니어로 근무하며 사내 인프라부터 서비스 상용 환경까지 ‘인프라’라 불리는 모든 것과 보안 전반을 담당하고 있다. 애플리케이션 배포 자동화를 수년간 추진해 온 경험을 바탕으로 6장을 집필했다. OpenVZ나 LXC 등 컨테이너 타입의 가상화 기술에 관심이 많다.
저자 : 이노우에 후미아키
주식회사 캐논에서 소프트웨어 엔지니어, QA 엔지니어를 거쳐 현재는 캐논의 자회사인 중국 법인에서 경리부를 총괄하고 있다. 개발 경험을 살려서 효율적인 자동화 테스트를 구현하고 있으며, 7장 집필을 담당했다.
역자 : 김완섭
네덜란드 ITC에서 GIS(지리정보시스템) 연계 재난재해 관리학(석사)을 전공했다. 약 9년간 한국 및 일본 대기업에서 다양한 IT 분야 업무를 담당했다. 일본에서는 시스템 엔지니어로 5년간 근무했으며, 일본 대기업 세콤(SECOM) 계열사인 파스코에서 외무성, 국토지리정보원 등 일본 정부 기관을 대상으로 한 시스템 통합S(I) 업무를 담당했다. 이후 야후재팬으로 직장을 옮겨 야후맵 개발 담당 시니어 엔지니어로 근무하다 2010년 귀국하여 SK에서 내비게이션 데이터 담당 매니저로 근무했다. 저서로는 《나는 도쿄 롯폰기로 출근한다》가 있으며, 역서로는 《SQL 더 쉽게, 더 깊게》, 《빅 데이터 시대의 하둡 완벽 입문》, 《웹 서비스 개발 철저 공략》, 《코딩을 지탱하는 기술》, 《따라하며 배우는 서버 부하분산 입문》이 있다.
품목정보
- 발행일
- 2014년 10월 10일
- 쪽수, 무게, 크기
- 362쪽 | 629g | 170*225*18mm
- ISBN13
- 9791185890067
책 속으로
|
다수의 인력이 문제를 공유하고 어떤 문제가 일어 났는지 알기 쉽게 공유해서, 디그레이드가 발생하지 않도록 테스트를 자동화하는 것이 중요하다. 또한, 무언가를 실수했을 때는 바로 원 상태로 복구하는 것도 중요하다. 한편, 신기능을 빠르게 개발해서 배포하지 않으면 시장 경쟁에서 밀리기 때문에 병행해서 복수의 기능을 개발해야 한다. 물론, 품질도 유지하면서 말이다.
_4쪽 다수의 멤버가 애플리케이션을 개발하다 보면 수정 부분이 겹쳐서 충돌이 발생하는 경우도 있다. 충돌이 발생한 경우에는 양쪽 수정이 모두 동작하도록 머지해 주어야 하지만, 이 작업이 쉽지 않다. 또한, 각 멤버가 머지를 해 줄지도 보장되지 않는다. 머지를 빼먹고 다른 사람이 수정한 것에 덮어쓰기 해도 눈치채지 못하는 경우가 있다. _37쪽 데이터베이스 스키마를 버전 관리하려면 무엇을 어떻게 관리하면 되는 것일까? 구체적으로 살펴보자. 여기서는 데이터베이스로 MySQL이나 PostgreSQL 등의 RDBMS를 사용하는 경우를 전제로 해서 이야기를 진행하겠다. 단, 데이터베이스가 RDBMS가 아닌 단순 파일이나 XML 파일, 객체형 데이터베이스이거나 최근 유행하고 있는 MongoDB(몽고디비) 등의 NoSQL 데이터베이스라도 방식은 같다. _104쪽 GitHub나 Backlog 같은 시스템을 사용하면 티켓 관리 시스템과 버전 관리 시스템 연계가 쉽지만, Git 자체를 수정할 수 없어서 자유도나 유연성에 한계가 있다. 앞서 언급한 시스템은 주로 Git 서버 측 후크인 Post-receive Hook를 공개하고 있을 뿐 모든 후크를 공개하고 있는 건 아니다. _153쪽 이와 같이 원래는 데이터베이스 값을 테스트에 맞게 설정해야 하지만, 실제 데이터베이스는 변경하지 않고 모크 객체를 사용해서 테스트를 만들 수 있다는 것을 알 수 있다. 참고로, 코드 예제에서는 다루지 않았지만 웹 서비스 API와의 접속 부분에 대해서도 동일하게 Mockito를 사용해서 모크를 만들 수 있다. 예를 들어, 웹 서비스에 접속하는 클래스가 항상 고정 JSON 응답을 반환하도록 모크를 만들면 된다. _201쪽 실제로는 복수의 커밋이 어느 정도 누적된 상태에서 브랜치가 작성되고, 이 브랜치가 상용 환경에 배포되는 흐름일 것이다. 여기서 중요한 것은 배포 파이프라인이 정체 없이 흘러가는 것이다. 각 단계가 사람에 의존한다는 이유로 배포할 수 없는 상황이 발생해서는 안 된다. 누구든지 테스트할 수 있고 배포까지 할 수 있는 것이 이상적이다. ---p.245 |
