Какие инструменты существуют, чтобы помочь собрать различные элементы программного обеспечения в полную версию программного обеспечения?
Автор вопроса: Didier TrossetОтветов: 6
Наш программный продукт состоит из многих частей. Допустим, он состоит из части драйвера ядра, пользовательской dll и программного обеспечения с графическим интерфейсом. Во время разработки мы компилируем и используем их все в последних версиях, но это не то же самое, когда дело доходит до релиза.
Действительно, часть ядра должна быть заморожена намного раньше, чем другая. Затем dll замораживается для тщательного тестирования, и последним замороженным является графический интерфейс. По мере продвижения QA нам нужно создавать новые версии полной версии с исправленным графическим интерфейсом, но с использованием ранее включенного драйвера ядра и dll.
Мне интересно, существует ли инструмент, который управлял бы какой версией каждой части программного обеспечения, используемой для создания выпуска?
Этот инструмент, возможно, будет интегрирован в цепочку инструментов для создания версии каждого выбранного программного обеспечения и объединения их в установщик Windows или пакеты Linux.
Изменить: как у нас дела?
На данный момент мы используем SVN с buildbot в качестве инструмента CI для Linux/gcc и Windows/VStudio. Мы находимся в режиме, когда весь репозиторий разветвляется/тегируется по мере необходимости. Но это больно и делает процесс выпуска болезненным сейчас, когда появляется все больше и больше относительно независимых частей программного обеспечения.
Мы думаем об изменении макета репозитория, чтобы иметь несколько независимых разветвленных/помеченных проектов. Это гораздо лучше соответствовало бы циклу разработки и выпуска программного обеспечения. Но тогда нам абсолютно необходим такой инструмент.
Проблема связана с тем, что разные части программного обеспечения, каждая со своими разветвленными/помеченными версиями, собраны в полную версию программного обеспечения.
Изменить: что необходимо.
В итоге я понял, что мне нужен менеджер пакетов для Windows. Менеджер пакетов в смысле менеджера RPM или DEB в Linux.
Кто-нибудь знает менеджер пакетов в Windows?
Я видел, как это решалось с помощью контроля версий с помощью соответствующих ветвлений, инструментов непрерывной интеграции и сценариев сборки. Что вы сейчас используете для построения вашей системы? Thomas Owens 02.12.2011
@ThomasOwens: ответил при редактировании вопроса. Didier Trosset 02.12.2011
Спасибо. Позвольте мне немного подумать об этом. Я постараюсь ответить, когда у меня будет ответ и несколько запасных циклов. Thomas Owens 02.12.2011
Один из способов, который я видел раньше, на техническом уровне в SVN, заключается в создании метарепозитория, который представляет собой просто набор внешних элементов для различных компонентов. Изменив внешние файлы так, чтобы они указывали на правильную ревизию, тег или ветку, а затем также пометив метарепозиторий, вы получите моментальный снимок этой конфигурации в SVN. Joris Timmermans 02.12.2011
Чтобы работать с исходным кодом, вы определенно хотите разветвлять свои компоненты по отдельности. Двоичные файлы обрабатываются через менеджер пакетов. Лучшие практики для этого будут различаться в зависимости от вашей целевой операционной системы. Моя компания занимается встраиваемым программным обеспечением, поэтому мы управляем этим с помощью разработанных нами пользовательских сценариев. В Linux вы хотите создавать пакеты .deb или .rpm. Вот руководство по Ubuntu. Я не очень хорошо знаком с Windows, но InstallShield - популярный выбор в программном обеспечении. мы установили.
Все они должны иметь механизмы для указания диапазонов версий зависимостей. Вы можете потребовать точную версию, определенную версию или новее или что-то среднее между двумя версиями. Тогда у вас есть "родительский" пакет, который не имеет двоичных файлов, а просто указывает версии пакетов компонентов. Это позволит вам обновить один компонент, сохранив при этом двоичные файлы для других компонентов. Если вы хотите сохранить все это в одном пакете, нет особых причин не просто собрать все это целиком из исходного кода. Если ваши сценарии сборки управляются версиями, ваши двоичные файлы будут такими же.
Ответ 2 · Otávio Décio
Один инструмент, с которым я играл, - это maven, он очень интересен тем, как он описывает различные жизненные циклы. . Вы можете использовать не только для java-проектов, но и для .net, и там есть много плагинов, а также хорошие репозитории (я использую один из сонатип).
Самое очевидное, что у вас есть, это проблема зависимостей между этими различными частями программного обеспечения (такими как ядро 1.0, драйвер A 1.1 и т. д.). Это создаст у меня впечатление, что вы должны подумать о своем инструменте сборки, если он способен управлять зависимостями, что не звучит так. Поэтому вам следует обратить внимание на Maven (уже упомянутый), SCons (я не уверен) или другие инструменты, такие как Ant в сочетании с Ivy. Вам нужно определить своего рода базовую линию, которая описывает, какие модули в какой версии работают вместе и могут быть выпущены. Это метаинформация, которую должен обрабатывать инструмент сборки. Вы можете создать что-то самостоятельно... но я не рекомендую этого делать.
Ответ 5 · JBrooks
У нас есть система, в которой "ствол" - это то, что находится в производстве. Мы создаем ветку для следующего релиза, когда разработчик вносит свои изменения в проблему, он регистрирует их в нашем менеджере релизов и связывает эти измененные файлы с этим номером проблемы или идентификатором ошибки.
Когда мы переходим к сборке, мы можем придержать все изменения для покупки задачи, просто не включив эту проблему в нашу сборку. Когда мы сворачиваем ветку, мы видим все файлы, которые были изменены, но не вошли в последнюю сборку - мы исключаем их из сворачивания.
Другая приятная часть этой системы заключается в том, что она берет все сценарии 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, либо мучиться с неисправной системой развертывания, пока она не будет исправлена.
