- Вопрос или проблема
- Ответ или решение
- Эффективное управление процессом выпуска программного обеспечения: BOM для кандидата на установку
- 1. Автоматизация процесса формирования BOM
- 2. Встраивание информации о версиях в компоненты
- 3. Извлечение информации из скомпилированных бинарных файлов
- 4. Сценарии и интеграция с Jenkins
- Заключение
Вопрос или проблема
Я работаю в компании, которая разрабатывает программное обеспечение.
Мы часто выпускаем программное обеспечение, которое представляет собой набор компонентов с разными версиями. Управление этим процессом несколько запутано. Существует ли программное обеспечение, которое может автоматизировать этот процесс, позволяя мне выбирать теги mercurial или git для каждой цели сборки, которые должны попасть в финальный релиз? То есть, нечто вроде спецификации материалов для выпусков программного обеспечения.
Пока мне не удалось найти подходящее решение. Меня удивляет, что для этого нет плагинов Jenkins.
Одним из удачных приемов является встраивание информации о сборке в каждый компонент как часть процесса сборки, а на этапе компоновки в релиз извлечение этой информации обратно.
Существуют несколько возможных способов встраивания информации в каждый компонент, (точные детали могут зависеть от языка, на котором написан компонент):
- В процессе получения/выгрузки создать один или несколько файлов, содержащих информацию о ветке/теге и версии.
- Во время сборки запросить систему управления версиями и состояние каталога чтобы либо убедиться, что нет незакоммиченных изменений, либо учесть, что они есть и обработать это в аналогичные файлы. Лично я предпочитаю разрешать сборки измененного кода с , чтобы разработчики могли тестировать свой код.
Сгенерированные файлы затем используются для встраивания информации во время процесса сборки, обратите внимание, что хорошей идеей является использование другого расширения файлов, чем обычно, чтобы вы могли указать системе управления версиями игнорировать его.
Если собранные компоненты исполняемы в среде сборки, каждому из них можно задать опцию --version, которая сообщает их название и сгенерированную информацию, а затем завершается. Все они могут быть запущены с флагом –version, и это можно перенаправить в файл, который станет входными данными для вашей спецификации материалов.
Если ваши компоненты не исполняемы в среде сборки, например, вы кросс-компилируете для встроенной цели, то вы можете пометить свою информацию о версии и извлечь ее из бинарных файлов. Один из стандартных способов сделать это – использовать старый формат sccsid строки идентификатора, например, для C/C++ вы можете использовать:
static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";
Это состоит из символов @(#), за которыми следует ваша информация о версии, и завершается любым символом нуля или символом новой строки.
Затем вы можете использовать утилиту what для извлечения этой информации из бинарных файлов в любой момент времени и снова перенаправить ее в вашу спецификацию материалов.
Это доступно на ряде операционных систем, или вы можете написать свою собственную.
Если ваша среда сборки основана на Unix/Linux, то генерация этой информации может быть выполнена с помощью sed и пайпов, или это можно сделать довольно просто с помощью скриптов на python, как и создание вашей спецификации материалов из полученной информации. Jenkins может с удовольствием выполнять скрипты на python в качестве шага в ваших процессах сборки/релиза. Кроме того, ваши тесты могут использовать ту же функцию для встраивания точной версии, которую тестировали, в результаты тестирования.
Ответ или решение
Эффективное управление процессом выпуска программного обеспечения: BOM для кандидата на установку
В современных условиях разработки программного обеспечения (ПО) компании сталкиваются с множеством вызовов, связанных с управлением версиями компонентов, интеграцией различных модулей и подготовкой релизов. Одним из ключевых инструментов для упрощения этого процесса является Bill of Materials (BOM) — детализированный список всех компонентов и их версий, которые входят в релиз. В этой статье мы обсудим, как автоматизировать процесс формирования BOM для генерации кандидата на установку программного обеспечения.
1. Автоматизация процесса формирования BOM
Хотя на первый взгляд может показаться, что подходящих решений немного, существуют множество инструментов и методик, которые могут значительно облегчить задачу. Среди них:
-
Интеграция с системами контроля версий: Используйте системы контроля версий, такие как Git или Mercurial, для хранения информации о версиях ваших компонентов. Этот подход позволяет вам выбирать соответствующие теги веток, которые должны войти в финальный релиз.
-
Плагины для CI/CD систем: Хотя вы упоминали, что не нашли подходящих плагинов для Jenkins, можно рассмотреть возможность создания собственных скриптов для автоматизации. Jenkins позволяет использовать различные языки программирования, такие как Groovy или Python, для написания шагов в пайплайне, которые будут собирать необходимую информацию о версиях из ваших компонентов.
2. Встраивание информации о версиях в компоненты
Для создания надежного BOM, эффективным подходом является встраивание информации о версиях непосредственно в каждую сборку. Вот несколько способов, как это можно сделать:
-
Создание файлов с информацией о версиях: Во время процесса извлечения (fetch/checkout) из системы контроля версий можно автоматически генерировать файл, который будет содержать информацию о ветках, тегах и версиях. Эти файлы могут быть игнорированы системой контроля версий, чтобы избежать конфликтов.
-
Запись статуса сборки в процессе компиляции: На этапе сборки вы можете выполнять команды, которые будут проверять состояние каталога в системе контроля версий. Такой подход позволит успешно компилировать модифицированный код, включая в BOM информацию о том, что сборка произведена с изменениями.
-
Использование команды –version: Для компонентов, которые могут быть выполнены в среде сборки, вы можете добавить флаг
--version, который будет возвращать информацию о версии. Вы можете выполнить все собранные компоненты с этим флагом и сохранить вывод в файл, используемый для формирования вашего BOM.
3. Извлечение информации из скомпилированных бинарных файлов
Если ваша сборка предназначена для встраиваемых систем и не может быть выполнена в среде сборки, можно записывать информацию о версиях в сами бинарные файлы. Один из распространенных методов — использовать формат идентификаторов, например sccsid. Это позволяет встраивать информацию о версии прямо в код, а затем легко извлекать ее с помощью утилиты what.
4. Сценарии и интеграция с Jenkins
Для сборки BOM можно использовать скрипты на Python или команды Unix/Linux, такие как sed. Jenkins предоставит возможности для запуска этих скриптов как этапов в процессе сборки и релиза. Вы также можете использовать эти же методы для встраивания информации о версиях в результаты тестирования.
Заключение
Формирование BOM как часть процесса выпуска программного обеспечения может существенно улучшить управляемость и надежность ваших релизов. Хотя может показаться, что подходящих инструментов недостаточно, грамотное использование существующих технологий, таких как системы контроля версий и CI/CD платформы, вместе с правильными скриптами и методами встраивания информации о версиях, позволит вам наладить упорядоченный и эффективный процесс управления релизами. Это станет важным шагом на пути к улучшению качества вашей продукции и удовлетворенности клиентов.