Методологии разработки, когда сотни разработчиков работают над одним решением?

Наша организация состоит из около 200 разработчиков, которые постоянно работают над одним продуктом (используя Git контроля версий), который планируется выпустить в определенную дату.

Из-за огромного количества разработчиков мы пытаемся создать «кросс-функциональные» команды, в каждой из которых будет около 10 разработчиков, в результате чего в организации будет около 20 групп разработчиков.

Поскольку мы хотели бы поддерживать постоянно «высокий стандарт» (то есть, когда разработчик извлекает информацию, продукт должен быть, по крайней мере, должен быть компилируемым и т. Д.) Продукта в основном репозитории, мы хотели бы использовать какие-то качественные средства контроля.

Я немного не уверен, как сформулировать вопрос, но мне интересно, смогу ли я получить несколько советов по методологиям разработки для такой большой группы разработчиков, работающих над одним продуктом.

По нашему мнению, один конец спектра состоит в том, чтобы позволить каждому разработчику напрямую связываться с основным репозиторием, однако мы опасаемся, что из-за большого количества разработчиков / коммитов, что «основной репозиторий» может постоянно находиться в нерабочем состоянии, из-за чтобы у нас не было требовательных «ворот качества» для каждого коммита.

Другой конец спектра может быть похож на (мы думаем, что Линус Торвальдс / Linux делает это) структуру дерева или пирамиды, где «основной репозиторий» имеет только три источника извлечения, эти три имеют только несколько надежных источников извлечения и т. Д. Однако мы чувствуем, что с такой структурой изменения должны пройти длинный путь, чтобы попасть в «основной репозиторий». Кроме того, если возникает конфликт слияния, проблема возникает у другого разработчика, чем «первоначальный разработчик».

С учетом всей этой исходной информации и высказанных мнений, как мы можем изучить и прочитать рекомендуемые методологии разработки для стольких разработчиков? Как крупные организации (Microsoft, Facebook, Ubuntu и т. Д.) Структурируют свое развитие?

Вам, безусловно, следует подумать о том, чтобы разделить продукт на модули с помощью команды (интерфейсов), объединяющей эти составляющие модули в продукт. Это, в свою очередь, будет означать разделение репозиториев в соответствии с разделением модуля и иерархией. Если окажется, что вы не можете этого сделать, то проект, вероятно, превратится в остановку, вызванную слиянием, учитывая количество разработчиков.

Если вы планируете использовать Git для контроля версий, я бы порекомендовал использовать систему проверки кода (например, Gerrit ) для повышения прозрачности и обеспечения качества для каждого репозитория. Таким образом, вся работа должна быть одобрена, прежде чем она будет объединена с любым авторитетным хранилищем. В этом сценарии имеет смысл предоставить определенным доверенным лицам разрешения на передачу из хранилища в системе проверки кода в другое хранилище (также, возможно, в системе проверки кода). При правильном использовании это должен быть быстрый и очень полезный процесс, который не мешает процессу разработки.

Что касается проверки сборки, вам потребуется сервер непрерывной интеграции (CI) , целью которого является автоматическое создание и проверка кода. Под кодом проверки я подразумеваю, что код успешно компилируется и тесты проходят. Infact Jenkins (CI Server) может быть связан с системой проверки кода Gerrit как часть этапа проверки Gerrit , полностью автоматизируя процесс.

В дополнение к этим инструментам интеграции важно стремиться к частой интеграции как части методологии разработки, чтобы минимизировать время слияния.

Возможно, стоит рассмотреть процесс разработки Agile, такой как Scrum , цель которого - разбить сложный продукт на управляемые куски приращения продукта (называемые Sprints). Это обеспечит возможности интеграции между хранилищами.

Очевидно, что с командой разработчиков из 200 человек у вас должна быть какая-то иерархическая структура. Отдельное лицо или небольшая группа людей принимают решения о разработке программного продукта. Процесс разработки должен отражать это: вам нужны обзоры кода и тестирование на месте, чтобы убедиться, что создаваемое программное обеспечение действительно соответствует тому, что вы хотели создать (а также в целях качества).

Даже небольшим командам нужны лидеры, чтобы руководить командами и анализировать их работу при разработке отдельных компонентов. Это должны быть процессы контроля качества на уровне команды.

Так что, да, вы должны следовать иерархической структуре в отношении хранилища. Это должно соответствовать иерархической структуре проекта в целом.

Отдельные компоненты должны быть собраны и протестированы до определенного уровня соответствия, прежде чем вы даже подумаете о том, чтобы собрать их все вместе. Позволить 200 людям принять непосредственное участие в основном проекте было бы хаосом. У вас должны быть отдельные области для каждой группы, где люди могут фиксировать свои изменения на ежедневной основе, не влияя на основную сборку проекта.

Это очень хорошая вещь, если «изменения должны пройти длинную цепочку, чтобы попасть в главный репозиторий», потому что эта цепочка позволяет вам гарантировать качество. Может показаться, что все изменения сразу же будут применены к главному репозиторию, но на самом деле это будет просто огромной головной болью, поскольку у вас будет постоянно глючная и непригодная основная сборка вашего программного обеспечения.

Также хорошо, что «если возникает конфликт слияния, проблема ложится на другого разработчика» - в частности, разработчик более высокого уровня должен решить, как разрешить конфликт.

Когда у вас есть что-то большое и (как следствие) неуправляемое, выход состоит в том, чтобы разделить его на более мелкие и управляемые части.

Есть несколько шагов, которые помогут вам лучше поддерживать команду и проект:

1. разделить функциональность на модули. Функциональные возможности должны быть разделены на максимально независимые модули с использованием принципов высокой когезии, низкой связи и инверсии зависимостей. Первый принцип поможет вам создавать логически согласованные модули. Второй поможет сохранить эти модули максимально независимыми. Третий поможет одновременно разрабатывать зависимые модули (если модуль A зависит от модуля B, B должен предоставить интерфейс, который A может использовать, даже если B не полностью готов).

2. иметь четкую документацию. Когда так много людей работают вместе, вещи можно легко забыть или неправильно понять. Поэтому необходимо уделить особое внимание всей документации от требований к архитектурным решениям.

3. люди для задач (никогда не задачи для людей). Разделив функциональность на более мелкие наборы, создайте команды для работы с этими наборами. На этом этапе будет проще создавать команды, потому что вы уже знаете, над чем работает каждая команда. И такие задачи, как проверки кода, будут выполняться внутри каждой команды.

4. понятная система заданий. Каждый из 200 разработчиков должен четко знать, над чем работать. Это поможет вам отслеживать, что уже сделано, над чем работает каждый человек и сколько осталось работы.

5. управления источником. (Я думаю, что это хорошо описано в других ответах)))

И наконец, постарайтесь создать как можно более простую структуру команд и модулей. Вы не можете позволить себе сложности с таким огромным проектом.

В дополнение к другим ответам, предлагающим иерархическую структуру: это означает, что вам придется планировать моменты «интеграции» во времени, когда основное внимание уделяется перемещению кода вверх по иерархии и «объединению всего этого». Это мало чем отличается от небольших проектов с финальной фазой, где не выполняется никакой другой работы, кроме тестирования и исправления ошибок, только чаще. Поскольку вы работаете в большой группе, стремящейся к высоким стандартам, большая часть этого (настроение), вероятно, уже будет на месте.

В дополнение к ответу hotpotato (который находится непосредственно на отметке IMHO), я бы также предложил реализовать некоторые элементы контроля версий, как вы предлагаете. Когда мы переместили большую команду и кодовую базу в git для SCM, мы решили использовать так называемый метод «доброжелательного диктатора», аналогичный описанной вами модели.

В этом сценарии есть много различных ветвей полной базы кода, которые регулярно обновляются из их исходной ветки, но ответственность за продвижение кода в более видимые / общедоступные области лежит на одном человеке (или небольшой группе людей), и обычно привязан к процессу проверки кода. С хорошо организованной структурой ветвления это может работать очень хорошо. Для получения дополнительной информации, проверьте эту ссылку .

Я работал над огромной системой, в которой одновременно работало несколько сотен разработчиков, и около 150 миллионов SLOC. Это было на мэйнфрейме, поэтому мы не говорим о Visual Studio, но принципы все же можно принять.

Прежде всего, если вы используете Java, я бы определенно сказал, использовать Maven. Если вы используете VS, вы также можете использовать Nuget, хотя я не совсем уверен, есть ли он у Maven или нет (он тоже несколько другой). Использование системы, подобной этой, позволит вам вывести свои зависимости и позволить им функционировать индивидуально. У вас будет скрипт сборки, который извлекает соответствующие зависимости и собирается как пакет.

Учитывая, что вы не задаете вопрос напрямую, а запрашиваете методологию, я расскажу вам, как мой предыдущий работодатель справился с ним.

Система была разбита на кластеры . Кластеры представляли сферы бизнеса и инфраструктуры системы. Я не буду их называть, но для огромного розничного бизнеса вы можете подумать о таких вещах, как маркетинг, розничные операции, онлайн-операции, закупки, дистрибуция. Системная инфраструктура представлена ​​такими вещами, как клиенты и безопасность. Внутри каждого кластера были компоненты . Используя предыдущую аналогию, вы могли бы рассмотреть, например, компоненты безопасности - единый вход, службы каталогов, аудит, отчетность и т. Д. В каждом компоненте были сохранены относительные процедуры.

Например, в качестве пространства имен или пакета вы можете использовать Organisation.Security.DirectoryServices. Содержа всю логику в соответствующих областях, команды работали достаточно автономно. Очевидно, что крупные проекты, требующие участия нескольких групп, имели место, но они были в основном бесперебойными.

Надеюсь, это поможет.