Вы помещаете сборки в репозиторий исходного кода?

Question

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

Плюсы:

• Можно легко получить предыдущие распределения, без необходимости зависеть от (potientially больше не доступны) из современных инструментов для перекомпиляции.

Минусы:

• может быстро "наворотов" репозиторий кода, в зависимости от частоты билдов.

Answer 1

Мы храним релизы в структуре каталогов и помещаем соответствующие версии в исходный код. Это дает нам доступ к встроенным версиям и источнику, который их создал.

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

Answer 2

Компромисс: хранить инструменты и исходный код в сборниках репозитория и тегов. Таким образом, вы всегда можете воссоздать любую сборку продукта.

И вы всегда можете иметь отдельный репозиторий для скомпилированных артефактов.

Answer 3

Поместите конкретные репозитории клиентов в хранилище.
Теоретически это не обязательно, так как мы всегда можем воспроизвести эту версию, но приятно иметь возможность получить точный .msi, который был отправлен определенному клиенту на определенную дату, - тогда мы проверяем это на чистом vm.

Одна из причин заключается в том, что она защищает вас от любых изменений вне вашей среды сборки, например, от Windows или визуального обновления студии. Возможно, вы не сможете воспроизвести бит-битовую сборку msi, если сам msi обновился!

Answer 4

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

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

Answer 5

Мы отправляем для маркировки репозитория для любой сборки, чтобы мы могли получить фактический источник для любого номера сборки &, затем мы заархивируем и загрузим фактические опубликованные файлы сборки, которые фактически развернуты, - просто чтобы убедиться, что нет скрытой конфигурации последней минуты твики и т. д. во время развертывания, которые не отражаются в самом багажнике.

Answer 6

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

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

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

Answer 7

Иногда. Большую часть времени ответ нет, но есть еще сценарии, где, если это имеет смысл, сделайте это.

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

Answer 8

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

Answer 9

Я хранил сборки на папке на сервере, и они были скопированы на регулярной основе. Но я помещаю ревизию, которая представляет эту сборку. В папке сборки я храню не только исполняемые файлы, двоичные файлы или страницы (наш случай - это ASP.Net), но и сценарии изменений, которые мы получаем из SQL Delta.

Теги называются с тем же идентификатором, что и поля, поэтому, если у вас есть сборка «System_2009-07-30-01», у вас будет тег с этим именем. Поэтому, если вам нужно что-то исправить, вы просто смотрите на имя сборки, смотрите тег, а затем смотрите ревизию, необходимую для просмотра того, что может произойти.

Answer 10

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

Answer 11

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