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

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

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

текст

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

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

вопросы

  1. как вы начинаете использовать git? У меня есть опыт работы с центрально расположенными системами управления версиями, такими как необходимости и SVN. Читая документацию, кажется, что все, что вам нужно сделать, это запустить git init pathtofolder и затем на другой машине запустите git clone url?

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

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

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

9
c# continuous-integration git

3 ответов

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

4
  1. вы можете использовать файл протокола ("локальный протокол"), если все ваши клиенты имеют совместный доступ к вашему серверу.
  2. Если вы можете сделать dir или LS от вашего клиента... у вас есть url, который вам нужен.
  3. теги: как только вы клонируете РЕПО, вы можете проверить его на определенный тег.
  4. не совсем, Вы будете получать каждое утро новые коммиты, чтобы получить полную историю.

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

1

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

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

    URL-адрес может быть filepath, networkpath, SSH-хост с path и т. д.

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

  4. возможно, вы могли бы перебазировать репозиторий git, чтобы удалить старые версии. См.полностью удалить (старый) git commits из истории

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

1