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

615

15

장

조직 구조

에 변경 사항의 서브밋을 허용하도록 고려할 때 게이트키퍼가 되는 오버헤드를 감수할 것인지

를 결정해야 한다. 즉, 코어 팀이 패치를 검토하는 데 시간을 할애하면 더 나은 일을 할 수 있

을까?

15.10.215.10.2

성숙도 성숙도

서비스가 덜 안정적이거나 덜 성숙될수록 핵심 팀 외부의 사람들이 패치를 서브밋하도록 허용

하는 것은 더 어려워진다. 서비스의 핵심 골격이 자리를 잡기 전에 팀은 ‘좋은 것’이 어떤 것인

지 모르기 때문에 좋은 서브밋이 어떤 것인지 알아내려고 애쓸 것이다. 이 단계에서 서비스 자

체는 많은 변화가 일어나고 있다.

대부분의 오픈 소스 프로젝트는 첫 번째 버전의 핵심 부분이 완료될 때까지 신뢰할 수 없는커

미터들의 서브밋을 받지 않는 경우가 많다. 그리고 자신의 조직에 대해 유사한 모델을 따르는

것이 좋다. 서비스가 꽤 성숙돼 변경이 거의 없다면 (예: 장바구니 서비스 ) 이제 다른 기여를

위해 새로운 일을 시작할 때다.

15.10.315.10.3

도구 도구

내부 오픈 소스 모델을 가장 잘 지원하려면 몇 가지 도구가 필요하다.

pull

요청 (또는 이와 유

사한 것 )을 서브밋할 수 있는 기능이 포함된 분산 버전 제어 도구를 사용하는 것이 중요하다.

또한 조직의 규모에 따라 패치 요청을 논의하고 발전시키는 도구가 필요할 수도 있다. 이것은

완전한 기능을 갖춘 코드 검토 시스템을 의미할 수도 있고 그렇지 않을 수도 있지만, 패치에 인

라인으로 주석을 달 수 있는 기능은 매우 유용하다. 마지막으로, ...