Signadot спонсировал этот пост.
«О, да, — застенчиво сказал глава платформы:« Раньше у нас были интеграционные тесты, но в конце концов никто не хотел их поддерживать, и они в основном начали терпеть неудачу. Поэтому нам пришлось выключить их ».
То, что началось с лучших намерений — рано переломить изменения — стало бременем обслуживания по мере развития услуг. Схемы продолжали меняться, испытания продолжали ломать, и исправлять их, ощущались как проигрышная битва. Это знакомая история для команд, управляющих микросервисами: интеграционные тесты, созданные с большими надеждами, часто становятся ненадежными, ведущими командами либо преувеличивают, чтобы вообще отказаться от их обслуживания или отказаться от них.
Введите тени тестирования
Тестирование Shadow предлагает принципиально иной подход к обеспечению безопасного развертывания. Вместо того, чтобы полагаться исключительно на критерии, заглушки или хрупкие тесты интеграции, теневое тестирование запускает новые версии услуг наряду с текущим, обрабатывая тот же трафик для прямого сравнения. Это позволяет организациям проверять реальное поведение, не затрагивая пользователей. В отличие от традиционных испытаний на предварительную деятельность, тестирование тестирования:
- Запускает тестовые версии вместе с текущей версией.
- Включает в себя отправку одного и того же трафика как в тестовую версию, так и в стабильную версию для прямого сравнения.
- Требует минимального ручного обслуживания по сравнению с традиционными настройками тестов.
Тем не менее, мы должны упомянуть, что трафик не обязательно должен означать производственный трафик — он может включать в себя синтетически продуманные запросы, которые тщательно имитируют производственный трафик. Чем ближе этот репрезентативный трафик к реальным условиям, тем более ценными результатами теста, конечно.
Как отмечается в игре Microsoft Engineering Fundamentals, «тестирование тени снижает риски, когда вы рассмотрите возможность замены текущей среды (V-тока) на среду кандидатов на новую функцию (V-NEXT). Этот подход — это мониторинг и захват различий между двумя средами, а затем сравнивает и снижает все риски, прежде чем ввести новую функцию/релиз ». Эта способность безопасно проверять в реалистичных условиях делает тестирование тени бесценной стратегией для современных команд программного обеспечения.
Где сияет тестирование тени
Тестирование тени особенно полезно для микросервисов с частыми развертываниями, помогая услугам развиваться без нарушения зависимостей. Он подтверждает схему и API рано, снижая риск до воздействия потребителя. Он также оценивает эффективность в реальных условиях и обеспечивает надлежащую совместимость со сторонними услугами.
Давайте теперь сравним его с другими формами тестирования, которые знакомы большинству инженерных команд:
Подход к тестированию
Сильные стороны
Слабые стороны
Модульные тесты
Быстрый, надежный, сфокусированный на небольших единицах функциональности с ограниченной широким объемом, не покрывает интеграции
Интеграционные тесты (насмешки)
Совместно имитирует зависимости, изолирует неудачи хрупкими, часто устаревшими макетами
Сквозные тесты
Охватывает критические потоки с точки зрения бизнеса дорогостоящие, ловкие, трудно поддерживать
Тень тестирование
Использование реальных зависимостей, минимального обслуживания, обнаружения регрессий требует установки инфраструктуры, потенциальные препятствия на основе безопасности при использовании производственного трафика
Теперь вы можете спросить: «Разве это не похоже на Canarying или Feature Flaging?» Не совсем. Хотя все три управляют рисками в развертываниях, они выполняют разные роли:
- Канарские релизы — Постепенно развертывают изменения в небольшом подмножестве пользователей для мониторинга проблем, но сбои по -прежнему влияют на реальных пользователей.
- Функции флагов — Включить или отключить функциональность динамически, идеально подходит для контролируемых развертываний, но не для тестирования изменений на ранней стадии. Они часто являются поздней стадией в жизненном цикле разработки программного обеспечения и слишком громоздкими для небольших функций.
- Тень тестирование — Запускает новую версию параллельно с трафиком, безопасно проверяя бэкэнд. Это левый подход, который рано улавливает регрессии и проблемы с производительностью, сокращая сюрпризы на поздней стадии.
Тестирование тени не заменяет традиционное тестирование, а скорее дополняет его путем снижения зависимости от хрупких тестов интеграции. В то время как модульные тесты остаются необходимыми для проверки логики и сквозных испытаний, улавливающих сбои высокого уровня, теневая тестирование заполняет разрыв в реальной валидации без нарушения пользователей.
Как работает тестирование тени (технический обзор)
Тестирование тени следует общему шаблону независимо от окружающей среды и было реализовано такими инструментами, как Diffy из Twitter/X, которые ввели сравнения автоматизированного ответа для эффективного обнаружения расхождений.
Некоторые из ключевых аспектов таких инструментов:
- Выполнение трафика -Тестовая версия (V-NEXT) работает вместе с текущей версией, обрабатывая тот же трафик, что и стабильная версия для определения расхождений. Это обеспечивает прямое сравнение поведения, помогая более эффективно обнаруживать регрессии и несоответствия.
- Сравнение ответов — Выходы регистрируются и сравниваются с определением регрессий или неожиданного поведения. Необязательный компонент модели отслеживает общие закономерности и помогает интерпретировать различия, классифицируя то, что важно, а что нет, улучшая актуальность и точность сравнений.
- Наблюдаемость и метрики — Производительность и шаблоны ошибок анализируются для обеспечения стабильности перед полным развертыванием.
Окружающая среда, в которой проводится тени, может варьироваться, обеспечивая различные преимущества. Более реалистичные среды, очевидно, лучше:
- Постановка тени — Легче настройка, избегает проблем соблюдения и изоляции данных и может использовать синтетический или анонимный производственный трафик для безопасной проверки изменений.
- Производственное тестирование тени — обеспечивает наиболее точную проверку с использованием живого трафика, но требует защиты данных для обработки данных, соответствия требованиям и изоляции рабочей нагрузки.
Этот структурированный подход гарантирует, что изменение услуги будет подтверждено в реальных условиях при минимизации рисков развертывания.
Заключение
Тестирование тени — это не просто еще одна стратегия тестирования. Это изменение в том, как современные организации подходят к проверке программного обеспечения. Благодаря трафику в сейфе, с песочницами, команды могут устранить компромисс между скоростью и надежностью. Для организаций, устали от хрупкой природы традиционных интеграционных тестов, тени тестирование предлагает практическую, масштабируемую альтернативу, которая снижает риск при ускорении развития.
Если вы запускаете микросервисы в Kubernetes, Signadot позволяет командам легко запускать тени тестирования, будь то Linkerd, Istio или даже без сервисной сетки. С легкими средами, которые плавно интегрируются в трубопроводы CI/CD, организации могут:
- Разверните изолированные тестовые песочницы для каждой ветви и отправьте трафик для тестирования микросервисов с помощью интеллектуальных тестов.
- Сравните различные аспекты запроса/ответов в режиме реального времени между стабильной и тестовой версией.
Внедрение теневого тестирования в масштабе требует инфраструктуры, способной выделять среды тестирования, обработать изоляцию трафика и обеспечение наблюдения. Как вы используете тени тестирования в вашей организации? Мы хотели бы услышать о вашем опыте и лучших практиках.
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Анируд Раманатан является техническим директором Signadot, где он фокусируется на развитии нативного облака. До этого он работал в Google, сосредоточившись на базовых контроллерах Kubernetes и расширяемости. Он также является комитетом в проекте Apache Spark с акцентом на … Подробнее от Anirudh Ramanathan
