Использование Git для распространения ночных сборок в студии

Question

Короткая версия

Нужно раздавать ночные сборки 70+ людям каждое утро, они хотели бы использовать git , чтобы сбалансировать нагрузку при передаче, и хотели бы знать, есть ли подсказки, подводные камни или недостатки с этой идеей, прежде чем Я начинаю проектировать систему.

Длинная версия

Каждое утро нам нужно раздавать наши ночные сборки студии более 70 человек (художники, тестировщики, программисты, продюсеры и т. Д.). До сих пор мы копировали сборку на сервер и написали программу sync , которая ее извлекает (используя Robocopy внизу); даже при настройке зеркал скорость передачи неприемлемо мала, поскольку для синхронизации в пиковое время (непиковое время составляет примерно 15 минут) требуется до часа или дольше, что указывает на узкое место аппаратного ввода / вывода.

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

Вопросы

1. Как начать пользоваться git? У меня есть опыт работы с центрально расположенными системами управления источниками, такими как Perforce и SVN . Читая документацию, кажется, что все, что вам нужно сделать, это запустить git init path\\to\folder, а затем на другом компьютере запустить git clone url?

2. Где взять url для вышеуказанной команды git clone? Я могу определить? Мне кажется странным иметь URL-адрес, поскольку у git нет центрального сервера - или нет? например похож на бит-торрент трекер?

3. Что было бы лучшим вариантом для идентификации сборок, использования номеров или меток списка изменений?

4. Можно ли ограничить количество сохраненных ревизий? Это было бы полезно, так как в дополнение к ночным сборкам у нас также есть несколько сборок CI в течение дня, которые мы хотим распространять, однако не имеет смысла оставлять бесконечные ревизии числа. В Perforce вы можете ограничить изменения, установив свойство.

Answer 1

Я не думаю, что Git будет действительно полезен в вашей ситуации. Да, это распространяется, но не в случае "распространения чего-либо среди большего количества людей, насколько это возможно". Это не поможет вам снизить нагрузку на полосу пропускания, также будет дополнительная нагрузка, если вы будете использовать git поверх ssh. Может быть, вы должны сделать шаг назад и дать еще один шанс для протокола bittorrent.

Answer 2

1. Да, в этом суть.Создайте хранилище где-нибудь, и затем вы сможете клонировать его откуда-то еще.

2. Хранилище, которое вы инициализируете в 1), должно быть доступно с машины, на которую вы клонируете.Git не является сервером, но каждый репозиторий должен где-то получать свои материалы.Таким образом, все ваши 70+ машин должны будут знать, где они должны получить новую сборку.И если вы хотите распределить нагрузку, вам нужно выяснить, кто от кого получит свое обновление.

   URL-адресом может быть путь к файлу, сетевой путь, хост SSH с путем и т. Д.

3. Теги будут работать хорошо.

4. Возможно, вы могли бы перебазировать git-репо, чтобы удалить старые ревизии.См. Полное удаление (старых) git коммитов из истории

Однако я не думаю, что это решит вашу первоначальную проблему, распределив нагрузку.Другие пути должны быть исследованы.Например, может помочь многоадресное копирование, MQcast и MQcatch ?

Answer 3

1. вы можете использовать файловый протокол (" локальный протокол "), если все ваши клиенты имеют общий доступ к вашему серверу.
2. , если вы можете сделать dir или lsот вашего клиента ... вы получили URL, который вам нужен.
3. теги: как только вы клонируете репо, вы можете оформить заказ на определенный тег.
4. не совсем, вы будете получать каждое утроновые коммиты для получения полной истории.

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