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

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

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

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

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

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