Обсудить проект_
Если у вас есть ИТ-проблема, напишите нам в Telegram или оставьте ваши контакты, и мы свяжется с вами для детального обсуждения задачи
Разработка системы релизов для встраиваемого ПО
Разработка встраиваемого ПО — задача непростая. Любая ошибка может сделать из вашего чудесного устройства кирпич. Если к этому ещё добавить сложность починки руками клиента — то управление качеством ПО выходит на первый план.
Одним из аспектов, который помогает добиться этого является прозрачная и автоматизированная система релизов.
Одним из аспектов, который помогает добиться этого является прозрачная и автоматизированная система релизов.
Нашему клиенту требуется регулярно обновлять набор системных утилит в прошивке выпускаемых ими устройств. У каждой утилиты свой жизненный цикл. Иногда требуются точечные обновления и кастомизации. При этом надо отвязаться от рабочего места разработчика и ввести версионирование.
Отсутствие этих механизмов сильно усложняет отладку для технической поддержки и ухудшает клиентский сервис.
Отсутствие этих механизмов сильно усложняет отладку для технической поддержки и ухудшает клиентский сервис.
Итоги:
Создан набор инструментов для сборки, реализован механизм формирования сквозных релизов с возможностью кастомизации набора версий.
Задача:
Создать предсказуемый и управляемый процесс сборки и доставки программного обеспечения, не привязанный к конкретному разработчику
Период работы:
Примерно 3 недели, с учетом сбора требований, согласования релизного цикла на административном уровне, тестирования
Команда:
DevOps инженер, C++ разработчик, руководитель поддержки, тестировщик
Используемые инструменты:
QT5, STM32 Cube, gcc, Werf, Gitlab CI. Целевые платформы — armv7, armv8
Решение:
Сначала был исследован механизм сборки и инструменты разработчика. После этого в отдельный проект была выделена сборка служебных инструментов для кросс компиляции. Для решения проблемы длительного времени сборки инструментов был использован werf, с хранением кэша промежуточных слоёв в docker registry.
В итоге время пересборки образов инструментов, при условии небольших изменений, было сокращено с 2-х часов до считанных минут.
Это дало возможность отвязаться от рабочего места разработчика, освободить сотрудника от рутинных операций по сборке и предоставлению готовых приложений, исключить риски ошибки версией при передаче ответственному за релизы.
После этого совместно с разработчиком код был зафиксирован в репозитории, для проектов был разработан git flow, согласован релизный цикл и настроена автоматическая сборка.
Основная поставка выполнялась через deb пакеты с отдельной системой версионирования.
Для сборки пакета был разработан отдельный скрипт с хранимой в git конфигурацией. В конфигурации сборщика зависимостей были указаны используемые по умолчанию версии служебных утилит, а также действия, которые нужно было совершить над полученными артефактами после скачивания. При необходимости сборки полностью кастомизированного релиза можно было указать версию для каждой из зависимостей, сохранив при этом конфигурацию в истории проекта.
Также при сборке формировался файл с перечнем используемых версий, для последующей публикации в описании релиза.
Результатом работ стали:
В итоге время пересборки образов инструментов, при условии небольших изменений, было сокращено с 2-х часов до считанных минут.
Это дало возможность отвязаться от рабочего места разработчика, освободить сотрудника от рутинных операций по сборке и предоставлению готовых приложений, исключить риски ошибки версией при передаче ответственному за релизы.
После этого совместно с разработчиком код был зафиксирован в репозитории, для проектов был разработан git flow, согласован релизный цикл и настроена автоматическая сборка.
Основная поставка выполнялась через deb пакеты с отдельной системой версионирования.
Для сборки пакета был разработан отдельный скрипт с хранимой в git конфигурацией. В конфигурации сборщика зависимостей были указаны используемые по умолчанию версии служебных утилит, а также действия, которые нужно было совершить над полученными артефактами после скачивания. При необходимости сборки полностью кастомизированного релиза можно было указать версию для каждой из зависимостей, сохранив при этом конфигурацию в истории проекта.
Также при сборке формировался файл с перечнем используемых версий, для последующей публикации в описании релиза.
Результатом работ стали:
- Снижение риска ошибки при ручном формировании набора утилит.
- Снижение bus factor на проекте.
- Возможность для технической поддержки оперативно получить информацию о релизе, его составе и локализовать потенциальные проблемы.
Обсудить проект_
Если у вас есть ИТ-проблема, оставьте ваши контакты, и мы поможем составить план ее решения. Обещаем не слать спам.
Нажимая, я говорю «Да»
политике конфиденциальности
политике конфиденциальности
Контакты_
