Альтернатива двоичным файлам в Подрывной деятельности

• Subversion - это менеджер управления исходным кодом -> Двоичные файлы не являются исходными
• Если вы используете команду «svn up» для обновления продукции, все разработчики с разрешениями коммитов могут обновить / изменить / прервать производство?

Альтернативы: используйте непрерывную интеграцию, такую ​​как Hudson или Cruise Control.

Двоичные файлы, особенно ваши, но и сторонние, не имеют места в инструменте контроля версий, таком как SVN.

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

Для сторонних двоичных файлов вам понадобится инструмент управления зависимостями, такой как Maven2. Затем вы можете настроить локальный репозиторий Maven для обработки всех сторонних двоичных файлов (или просто полагаться на общедоступные). Локальное хранилище также может управлять своими собственными двоичными файлами.

Сервер непрерывной интеграции, такой как Hudson , может архивировать артефакты сборки. Это не поможет вашему аргументу «почему нет», но, по крайней мере, это альтернатива.

Размещение бинарных файлов в стволе или ветвях определенно излишне. Помимо того, что занимает место, как вы упомянули, это также приводит к несоответствиям между источником и двоичными файлами. Когда вы ссылаетесь на ревизию 1234, вы не хотите задаваться вопросом, означает ли это «сборка, полученная из источника в ревизии 1234,« против »двоичных файлов в ревизии 1234». То же правило избегания несоответствий применяется к автоматически сгенерированному коду. Вы не должны указывать версию, которая может быть сгенерирована при сборке.

OTOH Я более или менее в порядке, помещая двоичные файлы в теги . Таким образом, другим проектам легко использовать двоичные файлы других проектов через svn: externals, не создавая все эти зависимости. Это также позволяет тестировщикам легко переключаться между тегами, не нуждаясь в полной среде сборки.

Чтобы получить двоичные файлы в тегах, вы можете использовать следующую процедуру:

1. проверить чистую рабочую копию
2. запустить скрипт сборки и оценить результаты любого теста
3. если сборка в порядке, svn добавляет двоичные файлы
4. вместо фиксации в ствол или ветвь, помечайте непосредственно из своей рабочей копии следующим образом: svn copy myWorkingCopyFolder myTagURL
5. отбрасывайте рабочую копию, чтобы избежать случайные коммиты двоичных файлов в магистраль или ветку

У нас есть скрипт tagbuild для полуавтоматизации шагов 3 и 4.

Вы подразумеваете, что у Вас есть источники плюс результат сборки в том же репозитории?

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

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

Защитник ежедневного, отдельно имеющего версию сценария автосборки, чем только против двоичных файлов + код

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

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

Поскольку вещи как изображения не обладают понятием различия, ПОЧЕМУ Вы храните их в системе, которая существует запись, и сохраните различия между файлами?

Основанное на пересмотре устройство хранения данных о хранении историй изменений в файлах. Нет никакой meaingful истории изменений в данных (говорят) файлы JPEG. Такие файлы хранятся отлично также просто в каталоге.

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

Лучше хранить большие связанные двоичные файлы (и выходные файлы) в структуре каталогов и относиться к ним от процесса сборки.

Управление версиями должно иметь все, что необходимо сделать: svn co и затем создают. Это не должно иметь промежуточных звеньев или конечного продукта, поскольку это побеждает цель. Можно создать новый проект в SVN для результата и присвоить версию двоичному результату отдельно (для выпусков и патчей в случае необходимости).

На моих проектах у меня обычно есть рычаги постсборки для создания из специальной рабочей копии на сервере, а именно, в пути, достижимом от браузера HTTP. Это означает, после каждой фиксации любой [кто может считать внутреннюю сеть], может легко загрузить соответствующие двоичные файлы. Никакие проблемы непротиворечивости, момент, обновляя + путь к автоматизированному тестированию.

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

По моему опыту, мог хранение Банок в конце SVN в путанице.
Я думаю, что лучше сохранить файлы Банки в Репозитории Знатока как Nexus.
Это имеет также преимущества, что можно использовать dependecy руководящий инструмент как Знаток или Ivy.

"передача артефактов сборки в репозиторий подверсии" может быть хорошей идеей, если Вы знаете почему.

Это - хорошая идея для цели управления версиями, больше специально для:

Проблема Упаковки 1/

Если артефакт сборки не является просто exe (или dll или...), но также и:

• некоторые конфигурационные файлы
• некоторые сценарии для начинания/останавливания/перезапущения артефакта
• некоторый sql для обновления базы данных
• некоторые источники (сжатый в файл) для упрощения отладки
• некоторая документация (javadoc сжатый в файле)

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

Проблема развертывания 2/

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

• Вы производите много артефактов сборки
• те артефакты довольно длинны для воссоздания с нуля

затем наличие тех артефактов в VCS является хорошей идеей, чтобы не воссоздавать их.
Можно просто запросить их от среды до среды.

Но необходимо помнить:

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

• 2/Вы не должны хранить их в том же Репозитории Подверсии, начиная с Вашей разработки, фиксируется (число пересмотра) намного чаще, чем Ваши значительные сборки (те считали достойным гомологизации и производственного развертывания),
  Это означает артефакты, сохраненные, в котором второй репозиторий должен иметь соглашение о присвоении имен для тега (или для свойства) для легкого получения количества пересмотра разработки, из которой они были созданы.

Я уверен, что существуют тяжелые аргументы против этой плохой практики

У Вас есть неправильное предположение, что передача "артефактов сборки" к управлению версиями является плохой идеей (если Вы неправильно не формулировали свой вопрос). Это не.

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

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

Так, нет никакой причины, необходимо так бояться хранения "артефактов сборки" в управлении версиями. То, что можно хотеть сделать, должно сохранить их в отдельных местах.

Я предлагаю разделить их как:

 ProjectName
 |--- /trunk
 |    |--- /build
 |    |    |--- /bin        <-- compilers go here
 |    |    |--- /lib        <-- libraries (*.dll, *.jar) go here
 |    |    '--- /object     <-- object files (*.class, *.jar) go here
 |    '--- /source          <-- sources (*.java) go here
 |         |--- package1    <-- sources (*.java) go here
 |         |--- package2    <-- sources (*.java) go here

Необходимо настроить IDE или сценарии сборки для размещения объектных файлов в/ProjectName/trunk/build/object (возможно, даже воссоздающий структуру каталогов под.../получать).

Таким образом, Вы даете Вашим пользователям опцию контролю или/ProjectName/trunk, чтобы заставить полные условия строительства или/ProjectName/trunk/source получать источник приложения.

В../build/bin и../build/lib необходимо поместить компиляторы и библиотеки, которыми пользовались для компиляции конечного продукта, те раньше поставляли программное обеспечение пользователю. Через 5 или 10 лет у Вас будут они там, доступными для Вашего использования в некоторой возможности.

Во-первых, Подверсия (и все другие в наше время) не является менеджерами по управлению исходным кодом (я всегда думал, что SCM означает Управление конфигурированием ПО), но системы управления версиями. Это означает, что они хранят изменения в материале, который Вы храните в них, это не должен быть исходный код, это могли быть файлы изображений, растровые ресурсы, конфигурационные файлы (текст или xml), все виды материала. Существует только 1 причина, почему созданные двоичные файлы нельзя рассмотреть как часть этого списка, и поэтому можно восстановить их.

Однако думайте, почему Вы хотели бы сохранить выпущенные двоичные файлы там также.

Во-первых, это - система, чтобы помочь Вам, не сказать Вам, как необходимо создать приложения. Заставьте компьютер работать на Вас, вместо против Вас. Таким образом, что, если хранение двоичных файлов занимает место - у Вас есть сотни гигабайтов дискового пространства и супер быстрых сетей. Не грандиозное предприятие хранить двоичные объекты там больше (тогда как десять лет назад это, возможно, была проблема - это, возможно, почему люди думают о двоичных файлах в SCM как плохая практика).

Во-вторых, как разработчик, Вы могли бы быть довольны использованием системы для восстановления любой версии приложения, но другие, кто мог бы использовать его (например, обеспечение качества, тест, поддержка) не могли бы. Это означает необходимость в альтернативной системе для хранения двоичных файлов, и действительно, у Вас уже есть такая система, ее Ваш SCM! Используйте его.

В-третьих, Вы предполагаете, что можно восстановить из источника. Очевидно, Вы храните весь исходный код там, но Вы не храните компилятор, библиотеки, sdks и все другие подчиненные биты, которые требуются. То, что происходит, когда кто-то приезжает и спрашивает, "может Вы создавать меня версия, которую мы поставили 2 года назад, у клиента есть проблема с той версией". 2 года являются вечностью в наше время, у Вас даже есть тот же компилятор, который Вы использовали тогда? Что происходит, когда Вы проверяете весь источник только, чтобы найти, что недавно обновленный sdk является несовместимым с Вашим источником и сбоями с ошибками? Вы вытираете свое поле разработки и переустанавливаете все зависимости только для создания этого приложения? Можно ли даже помнить, каковы все зависимости были?!

Последняя точка является большой, для сохранения нескольких k дискового пространства, Вы могли бы стоить себе дней если не недели боли. (И в законе Дерна также говорится, что, какой бы ни приложение необходимо восстановить, будет тот, который потребовал, чтобы самое неясное, трудное настроили зависимость, Вы были когда-либо рады избавиться от),

Так сохраните двоичные файлы в своем SCM, не волнуйтесь по мелочам.

PS. мы засовываем все двоичные файлы в их собственный каталог 'выпуска' на проект, затем когда мы хотим обновить машину, мы используем специальный проект 'установки', который состоит из только svn:externals. Вы экспортируете проект установки, и Вы сделаны, поскольку он выбирает правильные вещи и помещает их в правильную структуру каталогов.