Оправдывает ли себя непрерывная интеграция? Я уверен, что да.
Группы по разработке программного обеспечения из разных отраслей признают непрерывную интеграцию ценной практикой. Некоторые считают ее «обязательной» частью эффективного жизненного цикла. Однако в некоторых критичных с точки зрения безопасности областях, в частности в аэрокосмической отрасли, до сих пор существует упорное сопротивление внедрению непрерывной интеграции. Некоторые могут думать, что непрерывная интеграция не может формально встроиться в DO-178B/C. Некоторые могут думать, что эта динамичность не вносит ничего практически ценного в строгий и детальный процесс разработки.
Эти опасения беспочвенны, и я могу показать, что проект DO-178C может выиграть от непрерывной интеграции.
Непрерывная интеграция направлена на то, чтобы втянуть деятельность по тестированию в процесс разработки, а не откладывать ее напоследок. Эта цель распадается на следующие задачи:
Интегрировать все части программного обеспечения, чтобы увидеть, как они подходят друг другу;
Проверить, не внесли ли недавние изменения какого-либо регресса;
Проверить функциональность вновь реализованных изменений (если применимо).
Эти задачи следует выполнять достаточно часто, чтобы можно было устранить все ошибки, прежде чем переходить к следующему этапу жизненного цикла.
«Любой проект DO-178C может выиграть от непрерывной интеграции.» Вам понадобится несколько предварительных условий, прежде чем внедрять непрерывную интеграцию:
Система контроля версий, чтобы хранить и извлекать артефакты проекта, связанные с инструментальным средством сборки;
Автоматические тесты и платформа выполнения тестов;
Средства анализа результатов тестов.
К счастью, особенности DO-178 в части тяжеловесных методологий разработки дают прочную базу для всех трех требований.
DO-178 предписывает всеобъемлющий контроль конфигурации и управление изменениями. Каждый отдельный запрос на изменение и результирующие изменения в артефактах должен отделяться и отслеживаться. Обычно автоматизация процесса сборки и наблюдения, как каждое последующее изменение встраивается в предыдущую сборку, – это только вопрос настройки инструментального средства управления конфигурацией.
DO-178 предписывает всеобъемлющий контроль конфигурации и управление изменениями. Каждый отдельный запрос на изменение и результирующие изменения в артефактах должен отделяться и отслеживаться. Обычно автоматизация процесса сборки и наблюдения, как каждое последующее изменение встраивается в предыдущую сборку, – это только вопрос настройки инструментального средства управления конфигурацией.
Основанное на требованиях тестирование – это одна из главных идей стандарта DO-178. Обычно код и тестовые случаи параллельно разрабатывают разные группы. Если стратегия тестов установлена, а инструментальные средства и среда тестирования настроены, ничто не мешает группе тестирования разрабатывать процедуры тестирования вместе с тестовыми случаями. Это означает, что если изменение кода развернуто, то все готово для непрерывной интеграции и, что важно – для непрерывного тестирования.
DO-178 требует установления через отслеживаемость. Обычно каждая отдельная функция отслеживается на соответствие требованиям. Тестовые случаи и процедуры также отслеживаются на соответствие требованиям. Матрицы отслеживания хранятся хорошо структурированным образом. Все готово для выбора соответствующего набора тестов и их запуска после изменения кода. Матрица отслеживания также будет содействовать анализу: вы сможете идентифицировать разрушенные части почти мгновенно.
«Особенности DO-178 в части тяжеловесных методов разработки дают
прочную базу для непрерывной интеграции.» Конечно, такой подход хорошо работает, если тестирование автоматизировано или хотя бы наполовину автоматизировано. Современные наборы инструментальных средств тестирования программного обеспечения от VectorCast, LDRA, Rational и других компаний дают прочную базу для автоматизации тестирования. Основанные на моделях среды разработки открывают новые горизонты для непрерывной интеграции по принципам программного обеспечения в цикле и аппаратного обеспечения в цикле. К непрерывной интеграции можно адаптировать даже выполняемые вручную визуальные тесты старой школы. Всегда существует способ организовать автоматический ввод. Вывод с экрана можно регистрировать для последующего анализа. Таким образом, все тесты, за немногими исключениями, можно адаптировать к стратегии: «Запустить автоматически, когда изменение будет готово, проанализировать результаты, когда это будет нужно.»
Соответствие – один из самых важных вопросов при разработке бортового программного обеспечения. Некоторые полагают, что каждое инструментальное средство должно быть квалифицировано для непрерывной интеграции. Это неверно. Стандарт DO-178C утверждает: «Инструментальные средства, которые используются для исключения, сокращения или автоматизации операций процесса жизненного цикла программного обеспечения, и результаты которых не верифицированы, нуждаются в квалификации.» Вы можете выбирать разные стратегии для выполнения требований стандарта DO-178, такие как:
Автоматизация и функциональность выбора удачного/неудачного прохождения могут квалифицироваться;
Выходные данные инструментальных средств могут проверяться;
Может использоваться комбинация квалификации и проверок.
«Это неверно, что каждое инструментальное средство должно квалифицироваться
для непрерывной интеграции.» Вы можете также пойти другим путем – разделить задачи непрерывной интеграции и сертификации. Вы можете провести формальную верификацию (также называемую прогоном на оценку) один раз в конце без использования инструментальных средств автоматизации. Если непрерывная интеграция применяется во всем проекте, вы можете быть уверены, что ваш код в хорошем состоянии и ваши тесты правильные и полные. Риск возникновения необходимости каких-то неожиданных дорогостоящих обновлений минимален
Поскольку непрерывная интеграция не предписывается органами по сертификации, некоторые могут попытаться избежать дополнительных затрат. Это ваш выбор, но сделайте его мудро. Время и ресурсы, потраченные на ранних этапах вашего проекта для введения автоматизации тестирования и непрерывной интеграции, потом окупятся. Вы будете вознаграждены меньшим количеством ошибок, возможностью избежать проклятья интеграции и снижением затрат на изменения на последующих стадиях проекта (Кривая Бека). Или отложите тестирование и заплатите цену ближе к сроку сдачи проекта, по мере исправления всех этих каскадных ошибок. При таких условиях каждое отдельное изменение будет проблемой (кривая Бема). Посмотрите на эти две кривые и решите, которую из них вы предпочли бы увидеть в вашем проекте.
