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

19

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

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

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

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

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

Pierre.Vriens
источник

Ответы:

10

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

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

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

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

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

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

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

Tensibai
источник
Этот ответ является вариацией того, к чему я привык (мэйнфреймы), когда мы делаем такие вещи по крайней мере 1,5 десятилетия или около того (до появления DevOps). Интересно, имеет ли смысл здесь добавить свой собственный ответ (для дальнейшего расширения этого ответа, как мы делаем это с CMN / ZMF, например, для «банков»), или просто перенести его на новый вопрос (с самоответом). Как вы думаете? Кроме того, мне любопытно, что за метафора стоит нового вопроса (со ссылкой на этот ответ)? PS: вы не возражаете, если я исправлю некоторые опечатки?
Pierre.Vriens
Нет проблем для редактирования :) Я сохранил это, Это не очень специфично для devops org ИМХО. Опять же, DevOps - это изменение организации, которое может помочь настроить лучшую автоматизацию, разделяя проблемы ... поэтому я называю это семафором, как в программировании, я не думаю, что это стоит вопроса, но это зависит от вас
Тенсибай
Хорошо, редактирование завершено (как обычно: откат / улучшение по своему усмотрению). Кстати, у вас есть "S" на клавиатуре?!?!?! Кроме того: о чем подумать на выходных: посмотрите мой новый мета-вопрос ... Приятных выходных! Время для садоводства здесь (обрезка ...)
Pierre.Vriens
8

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

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

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

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

Дан Корнилеску
источник
В вашем ответе есть много чего переварить (я не уверен, что понял его полностью). Но то, что вы написали о « проведении такого тестирования вне вашего процесса квалификации CI / CD »: я ожидаю, что конечный результат того, что будет произведено / доставлено, будет храниться в ваших средах QA и Prod (через CD, автоматический или ручной). Но это также « кажется » мне, что CI должен также доставлять свой вывод туда, в то время как «снаружи» кажется разделением или дублированием или чем-то, не так ли?
Pierre.Vriens
insideИ outsideссылки относительно цикла проверки ДИ. По сути, я подвергаю сомнению причину существования среды QA - большинство тестов, проводимых там, должны быть надежными и в конечном итоге выполняться как часть проверок CI, особенно в контексте непрерывного развертывания, - поскольку вы хотите выполнять их на каждой итерации CI (успешно по крайней мере, до этого момента) в любом случае.
Дан
7

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

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

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

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

Ромео Нинов
источник
хорошо, это должно помочь улучшить стабильность, мерси! Мой вопрос касается «тестовых» сред, поэтому очевидно, что «производство» не должно рассматриваться как таковое. Несмотря на тех, кто использует «производство» для тестирования, вы знаете поговорку « Лучший тест - это активировать его в работе, а если он не работает, просто выполнить откат / возврат! »?
Pierre.Vriens
@ Pierre.Vriens, "играть" в продукт ИМХО не мудро :) Такое разделение среды является намеренным. На предыдущей работе у нас было 5 разных сред .... Вот так servece
Ромео Нинов
1
«Я» согласен, что такая игра не является мудрой. Однако, что «вы» можете сделать с ковбоями (мой «термин», который я использую для таких япошек), которые продолжают делать это снова и снова, и каждый раз, когда они получают одобрение от своих менеджеров, чтобы обойти (например) ежемесячную активацию выпуска , еще одним исправлением (например, из-за их исправления за предыдущий день ..., которое внесло новую ошибку). Вы думаете, что это не происходит в реальном мире? Кстати: по поводу "замораживания" в вашем ответе, вы думаете, имеет смысл опубликовать вопрос типа "Что такое примеры реализации замороженной среды?"
Pierre.Vriens
@ Pierre.Vriens, для меня имеет смысл задать такой вопрос. Обычно это регулируется правилами компании, но разработчики создают довольно динамичную среду, и это может стать настоящим испытанием :)
Ромео Нинов
1
Это мой предпочтительный подход, так как он дает среду, в которой разработчики могут сразу же тестировать свои изменения в интегрированной среде, но сохраняет QA в чистоте до тех пор, пока код не будет готов к формальному тестированию
Taegost
3

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

Адриан
источник
3

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

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

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

hvindin
источник
Интересные точки зрения / дополнения, хотя в нем есть некоторые вещи, которые, возможно, вы хотите усовершенствовать / переработать: (1) «приложения» в этом контексте, что вы имеете в виду (некоторые примеры?) (2) любая идея, как это может работать в (старые добрые) среды мэйнфреймов (3) что здесь «смягчающего» в этом контексте? PS: дайте мне знать, если вы думаете, что я должен создать новый вопрос для любой из этих «вещей» (маркеров).
Pierre.Vriens