Top.Mail.Ru

Разработка системы релизов для встраиваемого ПО

Разработка встраиваемого ПО — задача непростая. Любая ошибка может сделать из вашего чудесного устройства кирпич. Если к этому ещё добавить сложность починки руками клиента — то управление качеством ПО выходит на первый план.

Одним из аспектов, который помогает добиться этого является прозрачная и автоматизированная система релизов.
Нашему клиенту требуется регулярно обновлять набор системных утилит в прошивке выпускаемых ими устройств. У каждой утилиты свой жизненный цикл. Иногда требуются точечные обновления и кастомизации. При этом надо отвязаться от рабочего места разработчика и ввести версионирование.
Отсутствие этих механизмов сильно усложняет отладку для технической поддержки и ухудшает клиентский сервис.

Итоги:

Создан набор инструментов для сборки, реализован механизм формирования сквозных релизов с возможностью кастомизации набора версий.

Задача:

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

Период работы:

Примерно 3 недели, с учетом сбора требований, согласования релизного цикла на административном уровне, тестирования

Команда:

DevOps инженер, C++ разработчик, руководитель поддержки, тестировщик

Используемые инструменты:

QT5, STM32 Cube, gcc, Werf, Gitlab CI. Целевые платформы — armv7, armv8

Решение:

Сначала был исследован механизм сборки и инструменты разработчика. После этого в отдельный проект была выделена сборка служебных инструментов для кросс компиляции. Для решения проблемы длительного времени сборки инструментов был использован werf, с хранением кэша промежуточных слоёв в docker registry.

В итоге время пересборки образов инструментов, при условии небольших изменений, было сокращено с 2-х часов до считанных минут.

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

После этого совместно с разработчиком код был зафиксирован в репозитории, для проектов был разработан git flow, согласован релизный цикл и настроена автоматическая сборка.

Основная поставка выполнялась через deb пакеты с отдельной системой версионирования.

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

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

Результатом работ стали:
  • Снижение риска ошибки при ручном формировании набора утилит.
  • Снижение bus factor на проекте.
  • Возможность для технической поддержки оперативно получить информацию о релизе, его составе и локализовать потенциальные проблемы.
Обсудить проект_
Если у вас есть ИТ-проблема, оставьте ваши контакты, и мы поможем составить план ее решения. Обещаем не слать спам.
Нажимая, я говорю «Да»
политике конфиденциальности
hello@softwarecats.dev
Новосибирск, ул. Демакова
23/5, оф.308
Контакты_

Еще про наши проекты: