수강생을 위해 준비한 기사 번역 "DevOps 사례 및 도구" OTUS 교육 프로젝트에서.

특히 팀이 성장함에 따라 팀에서 투명성과 공동 책임을 장려하는 행동이 있기 때문에 단일 저장소를 선택해야 합니다. 어느 쪽이든 도구에 투자해야 하지만 기본 동작이 명령에서 원하는 동작이라면 항상 더 좋습니다.

우리가 이것에 대해 이야기하는 이유는 무엇입니까?

Matt Klein이 기사를 작성했습니다. "모노레포스: 그러지 마세요!"  (번역자 주: Habré에 대한 번역 “단일 저장소: 하지 마세요”). 나는 Matt를 좋아합니다. 그는 매우 똑똑하다고 생각하며 그의 관점을 읽어야 합니다. 그는 원래 트위터에 설문조사를 게시했습니다.

번역 :
이번 설날에는 단일 저장소가 얼마나 우스꽝스러운지에 대해 토론하겠습니다. 2019년은 조용히 시작되었습니다. 이러한 취지에서 설문 조사를 제공합니다. 큰 광신자는 누구입니까? 지지자:
- 모노레포
- 녹
- 잘못된 설문조사 / 둘 다

내 대답은 "나는 말 그대로 그 두 사람입니다."였습니다. Rust가 어떻게 약물인지 이야기하는 대신, 단일 저장소에 대해 그가 틀렸다고 생각하는 이유를 살펴보겠습니다. 자신에 대해 조금. 저는 Chef Software의 CTO입니다. 우리는 약 100명의 엔지니어, 약 11~12년 전의 코드 베이스, 4개의 주요 제품을 보유하고 있습니다. 이 코드 중 일부는 다중 저장소(내 시작 위치)에 있고 일부는 단일 저장소(내 현재 위치)에 있습니다.

시작하기 전에: 여기서 설명하는 모든 주장은 두 종류의 저장소 모두에 적용됩니다. 제 생각에는 다른 유형보다 한 가지 유형의 저장소를 선택해야 하는 기술적인 이유가 없습니다. 어떤 접근 방식이라도 효과가 있을 수 있습니다. 그것에 대해 이야기하게 되어 기쁘지만, 하나가 다른 것보다 우월한 인위적인 기술적 이유에는 관심이 없습니다.

나는 Matt의 요점의 첫 번째 부분에 동의합니다.

대규모로 단일 저장소는 다중 저장소가 해결하는 것과 동일한 문제를 모두 해결하지만 동시에 코드를 긴밀하게 결합해야 하고 버전 제어 시스템의 확장성을 높이기 위해 엄청난 노력이 필요하기 때문입니다.

단일 저장소를 선택하든 다중 저장소를 선택하든 관계없이 동일한 문제를 해결해야 합니다. 릴리스는 어떻게 출시하나요? 업데이트에 대한 접근 방식은 무엇입니까? 하위 호환성? 프로젝트 간 종속성? 어떤 건축 스타일이 허용되나요? 빌드 및 테스트 인프라를 어떻게 관리합니까? 목록은 끝이 없습니다. 그리고 성장하면서 이 모든 문제를 해결하게 될 것입니다. 공짜 치즈는 없습니다.

나는 Matt의 주장이 내가 존경하는 많은 엔지니어(및 관리자)가 공유하는 견해와 유사하다고 생각합니다. 이는 구성요소를 작업하는 엔지니어나 구성요소를 작업하는 팀의 관점에서 발생합니다. 다음과 같은 말을 듣습니다.

• 코드베이스는 부피가 큽니다. 이 모든 정크가 필요하지 않습니다.
• 필요하지 않은 쓰레기를 모두 테스트해야 하기 때문에 테스트하기가 더 어렵습니다.
• 외부 종속성을 사용하여 작업하는 것이 더 어렵습니다.
• 나만의 가상 버전 제어 시스템이 필요합니다.

물론 이러한 점은 모두 정당합니다. 이는 두 경우 모두에서 발생합니다. 폴리 저장소에는 빌드에 필요한 것 외에도 자체 정크가 있습니다... 다른 정크가 필요할 수도 있습니다. 그래서 저는 "간단히" 전체 프로젝트를 확인하는 도구를 만듭니다. 또는 하위 모듈을 사용하여 가짜 단일 저장소를 만듭니다. 우리는 하루 종일 이곳을 돌아다닐 수 있었습니다. 그러나 나는 Matt의 주장이 주된 이유를 놓치고 있다고 생각합니다. 나는 그 이유를 단일 저장소에 찬성하여 크게 뒤집었습니다.

의사소통을 자극하고 문제를 보인다

리포지토리를 분리하면 조정과 투명성이라는 사실상의 문제가 발생합니다. 이는 우리가 팀에 대해 생각하는 방식(특히 개별 구성원이 팀에 대해 생각하는 방식)에 해당합니다. 우리는 특정 구성 요소에 대한 책임이 있습니다. 우리는 상대적으로 고립된 상태에서 일합니다. 우리 팀과 우리가 작업 중인 구성요소에 대한 경계는 고정되어 있습니다.

아키텍처가 더욱 복잡해짐에 따라 더 이상 한 팀만으로 관리할 수 없습니다. 머릿속에 전체 시스템을 갖고 있는 엔지니어는 거의 없습니다. 팀 B, C, D에서 사용하는 공유 구성 요소 A를 관리한다고 가정해 보겠습니다. 팀 A는 리팩토링하고 API를 개선하며 내부 구현도 변경하고 있습니다. 결과적으로 변경 사항은 이전 버전과 호환되지 않습니다. 어떤 조언이 있나요?

• 이전 API가 사용되는 모든 장소를 찾으십시오.
• 새로운 API를 사용할 수 없는 곳이 있나요?
• 다른 구성요소가 파손되지 않는지 확인하기 위해 고치고 테스트할 수 있나요?
• 이 팀이 지금 변경 사항을 테스트할 수 있나요?

이러한 질문은 저장소 유형과 무관합니다. B, C, D 팀을 찾아야 합니다. 그들과 대화하고, 시간을 알아보고, 그들의 우선 순위를 이해해야 합니다. 적어도 우리는 당신이 그러기를 바랍니다.

누구도 정말로 이것을 하고 싶어하지 않습니다. 이것은 단지 API를 수정하는 것보다 훨씬 덜 재미 있습니다. 그것은 모두 인간적이고 지저분합니다. 폴리 저장소에서는 간단히 변경하고 해당 구성 요소(B, C 또는 D가 아닐 수도 있음)를 작업하는 사람들에게 검토를 위해 제공하고 계속 진행할 수 있습니다. B, C, D 팀은 현재 버전을 그대로 유지할 수 있습니다. 당신의 천재성을 깨달으면 그들은 새로워질 것입니다!

단일 저장소에서는 기본적으로 책임이 이전됩니다. A팀은 부품을 변경하고 조심하지 않으면 즉시 B, C, D를 깨뜨립니다. 이로 인해 B, C, D가 A의 문 앞에 나타나서 A팀이 왜 어셈블리를 깨뜨렸는지 궁금해합니다. 이것은 A가 위의 목록을 건너뛸 수 없다는 것을 가르쳐줍니다. 그들은 무엇을 할 것인지에 대해 이야기해야 합니다. B, C, D는 움직일 수 있나요? B와 C가 가능하지만 D가 이전 알고리즘 동작의 부작용과 밀접하게 관련되어 있다면 어떻게 될까요?

그런 다음 우리는 이 상황에서 어떻게 벗어날 것인지에 대해 이야기해야 합니다.

1. 여러 내부 API를 지원하며 D가 사용을 중지할 때까지 이전 알고리즘을 더 이상 사용되지 않는 것으로 표시합니다.
2. 여러 릴리스 버전을 지원합니다(하나는 이전 인터페이스, 다른 하나는 새 인터페이스 포함).
3. B, C, D가 동시에 이를 수락할 수 있을 때까지 A의 변경 사항 릴리스를 지연합니다.

1개의 여러 API를 선택했다고 가정해 보겠습니다. 이 경우에는 두 개의 코드가 있습니다. 오래된 것과 새로운 것. 어떤 상황에서는 매우 편리합니다. 이전 코드를 다시 체크인하고 더 이상 사용되지 않는 것으로 표시한 후 D 팀과 제거 일정에 동의합니다. 기본적으로 폴리 및 모노 저장소와 동일합니다.

여러 버전을 출시하려면 분기가 필요합니다. 이제 A1과 A2라는 두 가지 구성 요소가 있습니다. B팀과 C팀은 A2를, D팀은 A1을 사용합니다. D가 앞으로 나아갈 수 있으려면 보안 업데이트 및 기타 버그 수정이 필요할 수 있으므로 모든 구성 요소를 출시할 준비가 되어 있어야 합니다. 다중 저장소에서는 기분이 좋은 오래 지속되는 분기에 이를 숨길 수 있습니다. 단일 저장소에서는 코드가 새 모듈에 생성되도록 강제합니다. 팀 D는 여전히 "이전" 구성요소를 변경해야 합니다. 여기에서 우리가 지불하는 비용을 모두가 볼 수 있습니다. 이제 코드 양이 두 배로 늘어났으며 A1과 A2에 적용되는 버그 수정 사항은 두 가지 모두에 적용되어야 합니다. 다중 저장소의 분기 접근 방식을 사용하면 이는 체리픽 뒤에 숨겨져 있습니다. 중복이 없기 때문에 비용이 더 저렴하다고 생각합니다. 실용적인 관점에서 볼 때 비용은 동일합니다. 두 개의 거의 동일한 코드베이스를 빌드, 릴리스 및 유지 관리하며 그 중 하나를 삭제할 수 있습니다. 차이점은 단일 저장소의 경우 이러한 고통이 직접적이고 가시적이라는 것입니다. 이것은 더 나쁘고 좋습니다.

마침내 우리는 세 번째 지점에 도달했습니다. 출시 지연. A의 변화가 A팀의 삶을 개선할 가능성이 있습니다. 중요하지만 긴급하지는 않습니다. 그냥 미루면 안 될까요? 다중 저장소에서는 이를 푸시하여 아티팩트를 고정합니다. 물론 우리는 D팀에게 이 사실을 알리고 있습니다. 따라잡을 때까지 이전 버전을 유지하세요! 이것은 당신이 겁쟁이 역할을 하도록 설정합니다. A팀은 D팀이 점점 더 오래된 버전을 사용하고 있다는 사실을 무시한 채 계속해서 구성 요소를 작업하고 있습니다(이것이 D팀의 문제입니다. 그들은 멍청합니다). 한편, D팀은 코드 안정성에 대한 A팀의 부주의한 태도에 대해 이야기를 하면 형편없게 이야기합니다. 몇 달이 지났습니다. 마지막으로 D팀은 업데이트 가능성을 살펴보기로 결정했지만 A팀은 변경사항이 더 많았습니다. A팀은 언제, 어떻게 D를 깨뜨렸는지 거의 기억하지 못합니다. 업그레이드는 더 고통스럽고 시간도 더 오래 걸립니다. 그러면 우선순위 스택이 더 아래로 보내집니다. A에서 분기를 만들도록 강요하는 보안 문제가 발생할 때까지. A팀은 시간을 거슬러 올라가서 D가 안정되었던 지점을 찾아 그곳에서 문제를 수정하고 출시 준비를 해야 합니다. 이것은 사람들이 내리는 사실상의 선택이며, 단연 최악입니다. 서로 무시할 수만 있다면 A팀, D팀 모두에게 좋은 것 같습니다.

단일 저장소에서 세 번째는 실제로 옵션이 아닙니다. 당신은 두 가지 방법 중 하나로 상황을 처리해야 합니다. 두 개의 릴리스 분기를 갖는 데 드는 비용을 확인해야 합니다. 이전 버전과의 호환성을 손상시키는 업데이트로부터 자신을 보호하는 방법을 알아보세요. 그러나 가장 중요한 것은: 어려운 대화를 피할 수는 없습니다.

내 경험상 팀이 커지면 더 이상 전체 시스템을 염두에 두는 것이 불가능하고 그것이 가장 중요한 부분이다. 시스템 내 불일치의 가시성을 개선해야 합니다. 팀이 자신의 구성 요소에서 벗어나 다른 팀과 소비자의 작업을 보도록 적극적으로 노력해야 합니다.

예, 다중 저장소 문제를 해결하기 위한 도구를 만들 수 있습니다. 하지만 대기업에서 지속적인 전달과 자동화를 가르친 경험을 통해 알 수 있듯이 추가 도구를 사용하지 않는 기본 동작은 여러분이 기대하는 동작입니다. 다중 저장소의 기본 동작은 격리입니다. 이것이 요점입니다. 단일 저장소의 기본 동작은 책임 공유와 투명성입니다. 이것이 요점입니다. 두 경우 모두 거친 가장자리를 부드럽게 만드는 도구를 만들겠습니다. 도구는 내가 원하는 문화를 강화해야 하고 문화는 작은 결정과 팀의 일상 업무에서 나오기 때문에 리더로서 매번 단일 저장소를 선택합니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

가장 큰 광신자는 누구입니까? 지지자:

• 모노레포

• 녹

• 잘못된 설문조사 / 둘 다

33명의 사용자가 투표했습니다. 13명의 사용자가 기권했습니다.

출처 : habr.com