수백 명의 개발자가 단일 솔루션을 개발할 때 개발 방법론?

우리는 특정 날짜에 릴리스 될 예정인 단일 제품 (개정 제어 Git 사용)에서 지속적으로 작업하는 약 200 명의 개발자로 구성된 조직입니다.

수많은 개발자로 인해 각 팀마다 약 10 명의 개발자가있는 "교차 기능"팀을 만들려고 노력하고 있으며 조직 내에 약 20 개의 개발 팀이 있습니다.

우리는 메인 리포지토리에서 지속적으로 "높은 표준"(개발자가 풀을 수행 할 때, 제품은 최소한 컴파일 가능해야 함을 의미 함)을 유지하기 위해 일종의 품질 게이트를 사용하려고합니다.

질문을 어떻게 표현해야할지 모르겠지만, 단일 제품을 개발하는 대규모 개발자 그룹을위한 개발 방법론에 대한 조언을 얻을 수 있을지 궁금합니다.

우리의 견해로는 스펙트럼의 한쪽 끝은 각 개발자가 기본 저장소에 직접 커밋하는 것이지만, 많은 수의 개발자 / 커밋으로 인해 "주 저장소"가 지속적으로 중단 될 수 있다고 우려합니다. 각 커밋마다 까다로운 "품질 게이트"를 가질 수 없습니다.

스펙트럼의 다른 쪽 끝은 (주요 리누스 토발즈 / 리눅스가 생각합니다) 트리 또는 피라미드 구조와 같을 수 있습니다. 여기서 "주 저장소"에는 세 개의 풀 소스 만 있고이 세 개에는 소수의 신뢰할 수있는 풀 소스 만 있습니다. 그러나 우리는 이와 같은 구조로 "주요 저장소"로 들어가기 위해 체인이 길어야한다고 생각합니다. 또한 병합 충돌이 발생하면 "원본 개발자"가 아닌 다른 개발자에게 문제가 발생합니다.

이 모든 배경 정보와 의견이 언급 된 상태에서 많은 개발자에게 권장되는 개발 방법을 배우고 읽을 수있는 방법은 무엇입니까? 대기업 (Microsoft, Facebook, Ubuntu 등)은 어떻게 개발을 구성합니까?

이러한 구성 모듈을 제품으로 통합 하는 인터페이스 팀을 통해 제품을 모듈로 분할하는 것을 고려해야 합니다 . 이는 결국 모듈 파티셔닝 및 계층 구조와 일치하도록 저장소를 분할하는 것을 의미합니다. 이 작업을 수행 할 수없는 것으로 보이면 참여한 개발자 수를 고려하여 프로젝트가 병합으로 인해 중단 될 수 있습니다.

버전 제어에 Git을 사용하려는 경우 Gerrit 와 같은 코드 검토 시스템 을 사용하여 투명성을 개선하고 각 저장소의 품질을 보장 하는 것이 좋습니다 . 그렇게하면 모든 작업을 권한있는 저장소로 병합하기 전에 승인을 받아야합니다. 이 시나리오에서는 신뢰할 수있는 특정 개인에게 코드 검토 시스템의 리포지토리에서 다른 리포지토리 (또는 코드 검토 시스템의 경우)로 푸시 할 수있는 권한을 부여하는 것이 좋습니다. 올바르게 사용하면 개발 프로세스를 방해하지 않는 빠르고 유익한 프로세스 여야합니다.

빌드 확인과 관련하여 코드를 자동으로 빌드하고 확인하는 것이 목적인 CI (Continuous Integration) 서버 가 필요합니다 . 코드를 확인한다는 것은 코드가 성공적으로 컴파일되고 테스트되었음을 ​​의미합니다. 실제로 Jenkins (CI 서버)는 Gerrit 검증 단계의 일부로 Gerrit 코드 검토 시스템에 연결되어 프로세스를 완전히 자동화 할 수 있습니다.

이러한 통합 도구 외에도 시간 병합을 최소화하기 위해 개발 방법론의 일부로 빈번한 통합을 위해 노력하는 것이 중요합니다.

그것은 가치가있을 수 있습니다 같은 애자일 개발 프로세스 고려 스크럼 목적으로 제품 증가 (라고 스프린트)의 관리 덩어리로 복잡한 제품에게 그것을 파괴하는 것입니다. 이는 리포지토리 간 통합 기회를 제공합니다.

분명히 200 명의 개발 팀과 함께라면 일종의 계층 구조가 있어야합니다. 개인 또는 소규모 그룹의 사람들이 소프트웨어 제품의 디자인에 대해 결정하고 있습니다. 개발 프로세스에는 다음 사항이 반영되어야합니다. 작성중인 소프트웨어가 실제로 작성하려는 소프트웨어와 품질 목적을 위해 일치하는지 확인하려면 코드 검토 및 테스트가 필요합니다.

소규모 팀이라도 팀을 이끌고 개별 구성 요소를 개발할 때 작업을 검토 할 지도자가 필요합니다. 또한 팀 수준의 품질 관리 프로세스 여야합니다.

따라서 저장소와 관련하여 계층 구조를 따라야합니다. 이는 전체 프로젝트의 계층 구조와 일치합니다.

개별 구성 요소는 모두 구성하기 전에 생각하기 전에 특정 수준의 적합성에 맞게 작성 및 테스트해야합니다. 200 명이 주 프로젝트에 직접 참여하도록 허용하는 것은 혼란입니다. 프로젝트의 주요 빌드에 영향을 미치지 않고 개인이 매일 변경 사항을 커밋 할 수있는 각 그룹마다 별도의 영역이 있어야합니다.

이 체인을 사용하면 품질을 보장 ​​할 수 있기 때문에 "주 저장소에 오기 위해 체인에 긴 체인이 걸리는 경우"가 매우 좋습니다. 그것은 수 있습니다 보인다 모든 변경 사항이 즉시 메인 저장소에 적용 할 경우 더 빨리,하지만 당신은 당신의 소프트웨어를 지속적으로 버그 및 사용할 수 없게 주요 빌드를해야합니다 같은 사실이 그냥 큰 두통이 될 것입니다.

또한 "병합 충돌이 발생하면 다른 개발자에게 문제가 발생합니다", 특히 충돌을 해결하는 방법을 결정하는 사람이 상위 레벨 개발자 여야합니다.

당신이 크고 결과적으로 관리 할 수없는 것을 가지고 있다면 탈출구는 더 작고 관리하기 쉬운 부분으로 나뉩니다.

팀과 프로젝트를 더 잘 유지하는 데 도움이되는 몇 가지 단계가 있습니다.

1. 기능을 모듈로 나누십시오. 기능은 높은 응집력, 낮은 결합 및 의존성 역전 원리를 사용하여 독립적 인 최대 모듈로 나누어야합니다. 첫 번째 원칙은 논리적으로 일관된 모듈을 만드는 데 도움이됩니다. 두 번째 모듈은 이러한 모듈을 가능한 한 독립적으로 유지하는 데 도움이됩니다. 세 번째 모듈은 종속 모듈을 동시에 개발하는 데 도움이됩니다 (모듈 A가 모듈 B에 의존하는 경우 B는 B가 완전히 준비되지 않은 경우에도 A가 사용할 수있는 인터페이스를 제공해야 함).

2. 명확한 문서를 가지고 있어야합니다. 많은 사람들이 함께 일할 때, 쉽게 잊혀지거나 오해 될 수 있습니다. 따라서 요구 사항에서 아키텍처 솔루션에 이르는 모든 문서에 특별한주의를 기울여야합니다.

3. 작업을위한 사람 (사람을위한 작업) 기능을 더 작은 세트로 나누고 나면 이러한 세트에서 작업 할 팀을 작성하십시오. 각 팀의 작업 내용을 이미 알고 있으므로 팀을 만드는 것이이 단계에서 더 쉬워집니다. 그리고 코드 검토와 같은 작업은 각 팀 내에서 수행됩니다.

4. 명확한 작업 시스템. 200 명의 개발자 각각은 무엇을해야하는지 분명히 알아야합니다. 이를 통해 이미 수행 한 작업, 각 직원이 수행중인 작업 및 남은 작업량을 추적 할 수 있습니다.

5. 소스 컨트롤. (나는 이것이 다른 답변에 잘 요약되어 있다고 생각합니다))

마지막으로 가능한 한 단순한 팀과 모듈 구조를 만들어보십시오. 그런 거대한 프로젝트로 복잡성을 감당할 수는 없습니다.

계층 구조를 제안하는 다른 답변 외에도, 그것은 계층에서 코드를 위로 옮기고 '모두 통합'하는 데 중점을 둔 '통합'시점을 예약해야 함을 의미합니다. 이는 테스트 및 버그 수정 외에 다른 작업이 더 자주 수행되지 않는 최종 단계의 소규모 프로젝트와 크게 다르지 않습니다. 높은 수준의 표준을 위해 노력하는 대규모 그룹에서 일하고 있기 때문에 그 중 대부분 (마음 프레임)이 이미 준비되어있을 것입니다.

핫 감자의 답변 (IMHO 마크에 직접 있음) 외에도 제안한대로 소스 제어 게이트를 구현하는 것이 좋습니다. 대규모 팀과 코드 기반을 SCM의 git으로 옮길 때, 우리는 설명 된 모델과 유사한 "benevolent dictator"방법을 사용하기로 결정했습니다.

이 시나리오에는 전체 코드베이스의 다양한 분기가 소스 분기에서 정기적으로 업데이트되지만 코드를보다 가시적 인 / 공개 영역으로 승격시키는 책임은 한 사람 (또는 소수의 사람들)에게 있으며 일반적으로 다음과 같습니다. 코드 검토 프로세스에 묶여 있습니다. 잘 구성된 분기 구조를 사용하면 실제로 잘 작동 할 수 있습니다. 자세한 내용은 이 링크를 확인 하십시오 .

나는 약 150M SLOC와 동시에 수백 명의 개발자가 동시에 작업하는 거대한 시스템을 연구했습니다. 이것은 메인 프레임에 있었으므로 Visual Studio를 사용하지는 않지만 원칙을 여전히 적용 할 수 있습니다.

우선, Java를 사용한다면 Maven을 사용한다고 분명히 말할 것입니다. VS를 사용하는 경우 Maven과 함께 있는지 여부에 대해 확실하지 않지만 Nuget을 사용할 수도 있습니다 (약간 다릅니다). 이와 같은 시스템을 사용하면 종속성을 가져 와서 개별적으로 작동 할 수 있습니다. 빌드 스크립트가 관련 종속성을 가져 와서 배치로 작성해야합니다.

직접 질문하지 않고 방법론을 요구한다는 점을 감안할 때, 이전 고용주가 어떻게 처리했는지 알려 드리겠습니다.

시스템이 클러스터 로 분리되었습니다 . 클러스터는 비즈니스 영역과 시스템 인프라 영역을 나타냅니다. 이름을 밝히지 않겠지 만 거대한 소매업의 경우 마케팅, 소매업 운영, 온라인 운영, 조달, 배포와 같은 것을 생각할 수 있습니다. 시스템 인프라는 고객 및 보안과 같은 것을 나타냅니다. 각 클러스터에는 구성 요소 가있었습니다 . 이전 비유를 사용하여 단일 사인온, 디렉토리 서비스, 감사,보고 등 보안 구성 요소를 고려할 수 있습니다. 각 구성 요소에는 관련 루틴이 저장되어 있습니다.

예를 들어 네임 스페이스 또는 패키지로 Organisation.Security.DirectoryServices가 있습니다. 팀은 관련 영역에 대한 모든 논리를 포함함으로써 상당히 자율적으로 작업했습니다. 분명히 여러 팀의 의견이 필요한 대규모 프로젝트가 발생했지만 원활하게 운영되었습니다.

이게 도움이 되길 바란다.