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

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

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

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

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

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

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

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

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

Дополнительную информацию можно найти ЗДЕСЬ.

Раньше мы использовали use Buckminster для управления уровнем интеграции развертывания программного обеспечения, к сожалению, это больше не поддерживается. некоторое время назад, и сейчас мы завершили переход на использование maven.

Остальная часть моего ответа не была затронута, но оставлена ​​здесь для справки.

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

На странице технического обзора:

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

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

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

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

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

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