마이크로서비스 아키텍처 구축(전면 개정판)

259

7

장

빌드

지를 정말로 이해하는지 검증하려고 제즈 험블

Jez

Humble

이 고안해낸 매력적인 세 가지 질문이 있

다. 다음과 같은 질문을 스스로에게 던져보면 흥미로울 것이다.

메인라인에 하루에 한 번 체크인하는가?

코드가 통합되는지 확인해야 한다. 다른 사람의 변경 사항과 함께 코드를 자주 확인하지 않으면 향

후 통합은 더 어려워진다. 단기 브랜치를 사용해 변경 사항을 관리하는 경우에도 가능한 한 자주

(적어도 하루에 한 번 ) 단일 메인라인

mainline

브랜치에 통합하라.

변경 사항을 검증하는 일련의 테스트가 있는가?

테스트가 없다면 구성적인 면에서 통합이 됐다는 사실을 알 수 있지만 시스템의 동작을 중단시켰

는지는 알 수 없다. 코드가 예상대로 동작하는지 확인할 수 없는

CI

는

CI

가 아니다.

빌드가 깨졌을 때 이를 수정하는 것이 팀의 최우선 일인가?

녹색 빌드 알림은 변경 사항이 안전하게 통합됐음을 의미하고, 빨간색 빌드 알림은 마지막 변경 사

항이 통합되지 못했음을 나타낸다. 빌드를 다시 통과시키려면 빌드 수정과 관련되지 않은 추가 체

크인을 모두 중지해야 한다. 더 많은 변경 사항이 쌓이면 빌드를 수정하는 데 걸리는 시간이 크게

늘어나기 때문이다. 필자는 며칠 동안 빌드가 중단된 팀과 함께 일한 적이 있으며, 결과적으로 빌

드를 통과시키고자 상당한 노력을 들여야 했다.

7.1.27.1.2

브랜치 모델 브랜치 모델

빌드와 배포에 관련된 몇 가지 주제가 제품 기능 개발을 위한 소스 코드 브랜치를 만드는 것만

큼 많은 논란을 일으키는