Какие существуют инструменты, помогающие собрать различные элементы программного обеспечения в полную версию программного обеспечения?

Question

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

Действительно, часть ядра должна быть заморожена намного раньше, чем другая.Затем dll-файл заморожен, чтобы его можно было тщательно протестировать, а последний замороженный - это GUI.По мере продвижения QA нам нужно создавать более новые версии полной версии с фиксированным графическим интерфейсом, но все еще с использованием ранее включенного драйвера ядра и dll.

Мне было интересно, если бы существовал инструмент, который быуправлять какая версия каждой части программного обеспечения используется для создания выпуска?

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

Редактировать : Как у нас дела?

На данный момент мы используем SVN с buildbot в качестве инструмента CI для Linux / gccи Windows / VStudio.Мы находимся в режиме, когда весь репозиторий разветвляется / помечается по мере необходимости.Но это больно и делает процесс релиза болезненным сейчас, когда появляется все больше и больше относительно независимых частей программного обеспечения.

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

Проблема связана с тем, что различные версии программного обеспечения, каждый со своими собственными разветвленными / маркированными версиями, собраны в полный выпуск программного обеспечения.

Редактировать : Что нужно.

В конце концов, я понял, что мне нужен менеджер пакетов для Windows.Менеджер пакетов в смысле RPM или DEB в Linux.

Кто-нибудь знает о диспетчере пакетов в Windows?

Answer 1

Чтобы справиться с вашим источником, вы определенно хотите разветвлять ваши компоненты по отдельности. Двоичные файлы обрабатываются через менеджер пакетов . Лучшие практики для этого будут различаться в зависимости от вашей целевой операционной системы. Моя компания занимается встраиваемым программным обеспечением, поэтому мы управляем этим с помощью пользовательских сценариев, которые мы разработали. В Linux вы хотите создавать пакеты .deb или .rpm. Вот руководство по Ubuntu. Я не очень знаком с Windows, но InstallShield - это популярный выбор программного обеспечения, которое я установил.

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

Answer 2

Мы используем Buckminster для управления уровнем интеграции развертывания программного обеспечения.

У нас есть различные репозитории кода (внутренние репозитории git и svn, а также ссылки на внешние библиотеки и репозиториинапример, PyDev ), и он прекрасно объединяет их, развертывая только те компоненты, которые необходимы для любой данной сборки.

со страницы Tech Overview :

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

Buckminster - это расширяемая мета-инфраструктура, включающая язык метаданных компонента и среду выполнения, которые могутвыполнять либо в автономном режиме, либо в качестве подключаемого модуля в Eclipse IDE.Хотя Buckminster можно использовать для решения общих проблем сборки, сборки и развертывания, он не является системой управления сборкой или компонентами как таковой.Buckminster может повторно использовать существующие инвестиции в широком спектре инструментов управления сборками и исходными кодами - Maven, ANT, CVS, SVN, PDE и т. Д. - и предназначен для наложения как можно меньшего количества ограничений на услуги, предоставляемые этими внешними инструментами.

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

Buckminster также прекрасно интегрируется с нашими Jenkins (урожденными Хадсон) серверами непрерывной интеграции.

Наконец, Buickminster позволяет нам перемещать наш основнойисходные хранилища из монолитного svn хранилища для ряда более мелкозернистых git хранилищ безопасным и управляемым способом.В этой версии мы переместили основной компонент нашего программного обеспечения из svn в собственный репозиторий git, и, хотя были некоторые проблемы с реинтеграцией, они были управляемыми.

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

Answer 3

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

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

Другая приятная часть этой системы состоит в том, что она берет все сценарии SQL и объединяет их (разумно) в 1 большой файл SQL, который используется для продвижения выпуска в Test, QA и затем Prod.

Больше можно найти ЗДЕСЬ.

Answer 4

Самое очевидное, что у вас есть, это проблема зависимостей между этими различными частями программного обеспечения (например, Kernel 1.0, Driver A 1.1 и т. Д.).Это создаст у меня впечатление, что вы должны подумать о своем инструменте сборки, если он способен управлять зависимостями, которые не похожи на это.Так что вам стоит взглянуть на Maven (уже упомянутый), SCons (я не уверен) или другие инструменты, такие как Ant в сочетании с Ivy.Вам нужно определить какую-то базовую линию, которая описывает, какие модули в какой версии работают вместе и могут быть выпущены.Это метаинформация, которая должна обрабатываться инструментом сборки.Вы можете создать что-то самостоятельно ... но я не рекомендую это делать.

Answer 5

Я думаю, что вам нужен термин Управление конфигурацией программного обеспечения . Здесь тоже есть довольно здоровенный документ: http://www.sei.cmu.edu/reports/87cm004.pdf.

Answer 6

Один инструмент, с которым я играл, это maven , он очень интересен тем, как выкладывает различные жизненные циклы.Вы можете использовать не только для Java-проектов, но и .net, и есть много плагинов, а также хорошие репозитории (я использую один из sonatype ).