Signadot спонсировал этот пост.
Поскольку облачные нативные архитектуры и микросервисы преобразовали способ создания приложений, наши среды тестирования остаются упорно укоренена в предыдущую эпоху. Традиционная прогресс окружающей среды — когда кодовые прыжки последовательно от разработки до QA до постановки до производства имели смысл для монолитных приложений, развернутых как единая единица. Но в мире распределенных систем и автономных команд этот линейный путь создает фундаментальные противоречия.
Микросервисы обещают независимую развертываемость и автономию команды, однако наши модели окружающей среды заставляют их вернуться к синхронизированному монолитному прогрессированию. Команда услуг платежей, готовая к отправке критических исправлений, должна по -прежнему ориентироваться в тех же жестких воротах окружающей среды, что и экспериментальная функция в службе рекомендаций. Это несоответствие между нашей архитектурой (распределенной) и нашей моделью тестирования (централизовано) создает значительное трение.
Текущий дефолт
Большинство организаций сегодня работают с многочисленными предварительно производственными средами, которые отражают производственную инфраструктуру:
В этой модели изменения кода перемещаются в пакетном виде через каждую среду, часто на запланированных каденциях. Это создает несколько критических узких мест:
- Очередь и раздор: Поскольку несколько команд делятся каждой средой, разработчики часто ожидают доступа к окружающей среде.
- Отладка сложности: Когда возникают неудачи, определение виновника среди многих недавних изменений становится «загадкой убийства».
- Медленные циклы обратной связи: Проблемы интеграции часто возникают только после того, как код объединяется, что требует дорогого переключения контекста для исправления.
Возможно, что касается, что этот подход вновь вводит процесс тестирования «водопада» в предположительно гибкую архитектуру. Изменения кода накапливаются в каждой среде и тестируются партиями, часто в фиксированных графиках. Это побеждает основное преимущество микросервисов — независимой развертываемости — заставляя команды вернуться к синхронизированным циклам высвобождения. При запуске комплексных тестовых люксов дорого и занимает много времени, организации естественным образом изменяются, создавая монолитный процесс тестирования для распределенной архитектуры.
Эти проблемы усугубляются как команды и услуги умножаются. Компании, с которыми я работал, регулярно сообщают, что инженеры тратят от 20 до 30% своего времени на управление проблемами, связанными с окружающей средой, а не на строительстве.
Новый подход
Ведущие инженерные организации, такие как Uber, Lyft и другие, впервые привели к принципиально различной модели: консолидация нескольких средам предварительной производительности (DEV, QA, постановка) в единую общую базовую среду с изоляцией приложений с помощью интеллектуального маршрутизации запросов.
Вместо того, чтобы поддерживать несколько последовательных сред, этот подход:
Например, при тестировании изменения в одну службу в архитектуре из 50 сервисов вы развертываете только эту модифицированную услугу, а не все 50. Тестовые запросы разумно направляются в тестовую версию только этой услуги, используя базовую линию для всего остального.
Важно отметить, что эта основанная на запросах изоляция означает, что каждый разработчик может самостоятельно проверять свои изменения, не мешая тестируемым потокам других. Больше не нужно ждать доступа к окружающей среде или беспокоиться о том, что чужой тест преодолел процесс проверки. Каждая песочница работает в изоляции на уровне запроса, даже при том, что он разделяет одну и ту же базовую инфраструктуру.
Настраиваемая изоляция данных
Общий вопрос об этом подходе: «Как насчет изоляции данных?» Решение представляет собой настраиваемую модель изоляции, которая дает вам лучшее из обоих миров:
- Общие данные по умолчанию: По умолчанию, песочницы обмениваются базой данных с изоляцией на основе арендаторов. Это неоценимо для тестирования с помощью реалистичных, подобных производственным данным-часто самым сложным аспектом традиционной репликации окружающей среды.
- Изоляция по требованию: В тех случаях, когда конкретные тесты требуют полной изоляции данных (например, разрушительных операций или миграций схемы), могут быть представлены временные запасы данных, посеяны с необходимыми данными и привязаны к жизненному циклу песочницы.
Эта гибкость позволяет командам сбалансировать преимущества общей инфраструктуры с требованиями изоляции конкретных сценариев тестирования.
Этот подход резко трансформирует опыт разработчика. Вместо того, чтобы ждать общих сред и тестирования партий, каждый разработчик получает свою собственную изолированную песочницу тестирования, причем время настройки измеряется за считанные секунды, а не часы. Самое главное, что он восстанавливает независимое обещание развертываемости микросервисов, позволяя командам проверять и отправлять изменения в своем собственном темпе.
Когда специализированные среды все еще имеют смысл
В то время как консолидация Dev, QA и постановки имеют смысл для большинства потребностей в тестировании, некоторые специализированные сценарии тестирования требуют отдельных сред:
Целевые среды тестирования
Определенные типы тестирования получают выгоду от выделенных сред:
- Тестирование производительности: Нагрузочные тесты могут нарушать нормальные операции и требовать специализированного мониторинга.
- Хаос Инжиниринг: Намеренно нарушение систем для проверки устойчивости по своей сути разрушительно.
- Валидация безопасности: Оценки на проникновение и уязвимость могут повлиять на доступность.
- Среда предварительного просмотра клиентов: Демонстрация новых функций для клиентов требует стабильности.
Требования к соблюдению
В регулируемых отразителях явное разделение может потребоваться для:
- Строгая изоляция данных, предписанная такими правилами, как HIPAA, PCI-DSS или FedRamp
- Аудиторские тропы, показывающие четкие границы между тестирующими и производственными системами
- Среда валидации, которые остаются статическими во время процессов сертификации
Создание специализированной среды эфемерной
Даже специализированные среды не должны быть навсегда подготовлены. По требованию среды, которые вращаются только при необходимости, обеспечивают чистые, последовательные условия испытания при устранении постоянных ресурсов. Например, компания по финансовым услугам может поддерживать одну постоянную базовую среду, но создать эфемерные среды для конкретных потребностей, таких как ежеквартальные аудиты безопасности или тесты производительности.
Гибридная модель: правильное размещение в вашей стратегии окружающей среды
Оптимальный подход объединяется:
Эта модель восстанавливает независимую перспективу развертываемости микросервисов, в то же время обеспечивая соответствующую изоляцию там, где это действительно необходимо. Вместо единого подхода, который заставляет все испытать одну и ту же форму, команды могут выбрать правильный подход к тестированию для каждого сценария.
Заключение
Традиционная прогрессия в многонациональной среде стала смещенной с облачными нативными архитектурами. Консолидируя DEV, QA и постановку в единую базовую среду с изоляцией приложений, организации могут восстановить независимую перспективу развертываемости микросервисов.
В то время как такие компании, как Uber и Lyft, создали доморощенные решения для этого подхода, такие платформы, как Signadot, теперь делают эти возможности доступными для инженерных команд всех размеров.
Будущее не вслепую дублировать среды, а о том, чтобы быть намеренным о том, когда и как мы изолируем наши системы.
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арджун Айер, генеральный директор Signadot, является опытным экспертом в облачной местной области с глубокой страстью к улучшению опыта разработчика. У Арджуна хвастается более чем 25-летним опытом работы в отрасли, есть богатая история разработки программного обеспечения для интернет-масштаба и … Подробнее от Arjun Iyer
