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

Question

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

Плюсы:

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

Минусы:

• Может быстро «раздуть» хранилище кода, в зависимости от частоты сборок.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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