Зависимости между ночными сборками и выпусками - проблема тестирования

Question

это вопрос процесса сборки релиза, который мне нужно решить для нашей команды SW.

Мы разрабатываем приложения для встроенных систем, основанные на нескольких общих библиотеках. Мы также внедрили ночные сборки и автоматическое тестирование ПО в oder, чтобы иметь возможность отследить ошибки как можно скорее. Приложения и библиотеки разрабатываются одновременно. Наша разработка находится в фазе бета-тестирования, поэтому мы не вводим новые функции, но в основном исправляем ошибки.

Развитие состоит в следующем: когда в приложении исправлена ​​ошибка, выполняется ночная сборка. Эта ночная сборка берет последнюю выпущенную стабильную библиотеку, компилирует приложение и выполняет тесты BlackBox на модуле HW - исполняемый файл результата передается в систему управления версиями и имеет уникальную версию сборки.

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

Может случиться, что нам нужно сделать релиз для пользователей из приложения, но библиотека все еще не стабильна, это сборка. В таком случае мы берем последнюю выпущенную версию библиотеки. НО, если за ночь до того, как была исправлена ​​библиотека, наши тесты выполнялись на APP сборки, конфигурация сборки LIB. Поэтому конфигурация сборки приложения, выпуск LIB не была проверена.

Подводя итог, мы имеем следующие возможности:

APP          LIBRARY
build        release
build        build
release      release
release      build

Но всегда компилируется только 1 комбинация, протестированная с нашей ночной сборкой.

Мой вопрос: как справиться с такой ситуацией? Из 1 ночной сборки я могу получить только 1 уникальную версию SW, но я бы хотел знать погоду и другие комбинации?

Может ли кто-нибудь предложить улучшение в нашем процессе, или мы делаем что-то совершенно неправильно? Любые ответы очень приветствуются. Спасибо.

открытка Аттила

Answer 1

Каждый исходный файл и библиотека находятся под контролем версий, и при создании новой сборки определяется, какую версию каждой из них вы используете. Например, сегодняшняя сборка может быть {App1_3.0, App2_3.2.5, ..., Lib1_2.0, Lib2_2.1, ...}. Если эта сборка пройдет ваши тесты, вы можете решить, что вам удалось исправить ошибку, скажем, в App2, и объявить App2_3.2.5 стабильным и благословенным. Но нет никакой причины проверять build в системе контроля версий . Все, что нужно, это помнить, какие версии вещей были включены в него (вектор номеров версий) и прошла ли тестирование тестирование. (Может оказаться полезным автоматизировать процесс сборки до того момента, когда будет легко воссоздать старую сборку по этому «рецепту», если вы этого еще не сделали.) Если по какой-то причине вы хотите присвоить этому уникальный номер построить, есть несколько способов сделать это.

• Используйте дату. Если вы строите несколько сборок за одну ночь, просто добавьте одну или две цифры.
• Используйте последовательный серийный номер. Если последняя сборка была # 1792, следующая будет # 1793.
• Если вы хотите, чтобы число содержало информацию об ингредиентах, просто объедините номера версий модулей (соблюдая осторожность с разделителем), чтобы номер в приведенном выше примере был 3.0.00.3.2.5.00 ... .2.0.00.2.1.00 ... И если это слишком долго, сожмите его - это очень сжимаемо.
• Хешируйте номера версий модулей. Или используйте случайное число, оно будет иметь тот же эффект.

Answer 2

Достаточно ли у вас системных ресурсов для сборки / тестирования всех 4? Вам не обязательно делать это ежедневно, только после изменения кода.