Как избежать нестабильности, вызванной непрерывной интеграцией в тестовых средах?

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

Но также предположим, что в вашем цикле тестирования участвуют другие люди, например, менеджеры или клиенты. Имеет ли смысл вовлекать других людей в попытки пересмотреть (сломать?) Ваши предстоящие изменения, не так ли?

Но если вы постоянно продолжаете вносить изменения в среду, в которой эти другие люди всерьез пытаются их протестировать, то могут возникнуть многочисленные проблемы, такие как:

• they может тратить свое время на сообщение о проблемах, которые к тому времени, когда они сохраняют (подробно) отчет, не могут даже больше воспроизвести проблему самостоятельно (например, потому что вы случайно столкнулись с той же проблемой и уже устранили ее в своей среде).
• you возможно, не сможет воспроизвести проблемы, о которых они сообщили, поскольку среды, в которых они столкнулись с какой-либо проблемой, больше не идентичны (вы (!!!) могли перекрывать их среду).

Так что вы можете сделать (как настроить вещи?), Чтобы избежать таких (разочаровывающих) ситуаций?

Я поделюсь своим опытом по этому вопросу, главным образом потому, что он показывает, почему некоторые ответы не всегда применимы.

Некоторый контекст для начала:

• У нас есть 7 сред для размещения примерно 80 приложений, большинство из которых зависят друг от друга через веб-сервисы или общие таблицы в db2-iSeries.
• Хорошо это или плохо, iSeries - наша справочная система БД.
• Этот последний пункт лишает законной силы идею переноса приложения с его зависимостями в изолированную среду, так как установка AS400 для каждого будет стоить слишком дорого, и у нас все равно не будет оборудования для его запуска.

То, что мы делаем, это не полная автоматизированная непрерывная доставка, у нас есть расписание выпусков, чтобы вывести согласованное множество приложений для общих операций. Кроме того, каждая группа тестирования может инициировать выпуск в одной из сред Q / A для приложения, которое они тестируют, и может заблокировать какую-либо версию приложения, чтобы другой запрос группы не нарушил их тесты.

Зависимости приложений проверяются перед выпуском, поэтому система не выпускает что-либо, если другие приложения не могут быть обновлены или не соответствуют необходимым зависимостям. Основная идея заключается в том, чтобы позволить обновления, когда они не будут влиять на кого-то, если тесты не запланированы, они должны исходить из предыдущей среды (и мы стремимся удалить запланированные выпуски в 5 первых средах в среднесрочной перспективе, теперь мы имеем проверил эту систему методов «по требованию»).

Короткая версия состоит в том, чтобы иметь «семафорную» систему вокруг приложений в среде, команда должна иметь возможность блокировать целевое приложение с его зависимостями (и переходными зависимостями) на время ручных тестов.
Реализация этого семафора сильно зависит от вашей системы автоматизации, поэтому я не буду останавливаться на этом.

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

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

ИМХО, вам не следует использовать такое тестирование в целях квалификации CI / CD, так как это фактически сделает недействительным ваш процесс квалификации (по крайней мере, в этой области). Утверждение о том, что программное обеспечение проходит тест X без фактического выполнения теста X для каждой поставленной версии программного обеспечения или без уверенности в том, что passполученный результат не является случайным (из-за ложных срабатываний), подорвет уровень достоверности вашего тестирования. Ложные негативы не наносят ущерба достоверности, но они также нежелательны из-за ненужного «шума», который они создают.

Это нормально выполнять такое тестирование вне вашего процесса квалификации CI / CD. Но в таком тестировании вы бы рассматривали неудавшийся результат так же, как обнаруженную клиентом ошибку: вам необходимо надежно воспроизвести проблему, чтобы иметь возможность разработать исправление для нее и подтвердить, что исправление работает. И вы не можете сделать это, если тестирование не является надежным.

Если вы планируете решить проблему, то в идеале вы должны сначала разработать автоматизированный, надежный контрольный пример для воспроизведения проблемы. Который вы использовали бы для разработки исправления и подтверждения его эффективности (результат теста должен перейти из FAIL в PASS). Вы также можете (должны?) Поместить этот тестовый сценарий в процесс квалификации CI / CD, чтобы предотвратить повторение в будущем, если это необходимо, для повышения общего уровня качества выпуска программного обеспечения.

Обычный подход заключается в создании разных сред:

DEV - это то место, где команда разработчиков бездельничает. Здесь создаются все изменения настроек, разворачивается новая версия и так далее. Здесь место, где CI полностью интегрирован.

PREPROD / QA - это место, где «играют» QA / test / validation, команда делает тесты. Эта среда обычно замерзает во время испытаний. Интеграция CI с этой средой заключается только в предоставлении новой версии продукта, конфигураций и т. Д.

ПРОИЗВОДСТВО - это нужно объяснять :)?

Если вы выполняете CI / CD, это означает, что перед развертыванием (CD) происходят некоторые автоматические тесты (CI). Если вы обнаружите много проблем в тестовой среде, это означает, что они не будут обнаружены тестами, выполняемыми до развертывания; это указывает на недостаточное автоматизированное тестирование. Если у разработчиков возникают проблемы, когда в тестовой среде возникают проблемы, им необходимо улучшить свои автоматизированные тестовые наборы, чтобы предотвратить это. Это также улучшит качество и надежность в целом, вплоть до производства.

Чтобы добавить ответ Ромео Нинова, внутри среды вам нужно постараться максимально разделить приложения. Это частично, почему Docker был настолько успешным для dev / test. Это позволяет вам почти притворяться, что вы не делитесь средой вообще.

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

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