Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Чаще всего продукты тестируют ближе к концу жизненного цикла разработки. Однако существует концепция Shift-left testing, принципиально изменяющая подход к тестированию. Команда VK Cloud перевела статью о применении концепции Shift-left testing при разработке с использованием Kubernetes, а также о некоторых стратегиях реализации этого подхода в микросервисной среде.
Что такое Shift-left testing
Shift-left testing — это набор приемов, которые переносят тестирование и обратную связь по нему на ранние этапы жизненного цикла разработки, то есть как можно ближе к моменту написания кода.
Относительная стоимость устранения дефектов на разных этапах разработки, по данным IBM System Science Institute
Чем позднее в цикле разработки ПО (Software development lifecycle, SDLC) обнаруживают баг, тем дольше его придется исправлять и тем дороже это будет стоить. При тестировании на ранних этапах можно перейти от обнаружения ошибки постфактум к ее профилактике.
Agile, DevOps и Shifting-left
Чтобы понять преимущества концепции Shift-left testing, посмотрим на историю вопроса. Сначала в разработке применялась каскадная модель Waterfall. Она охватывала узкоспециализированные разрозненные направления: проектирование, разработку, контроль качества и релиз. Эта модель прославилась низкой скоростью, перекладыванием ответственности с одной команды на другую и продолжительным циклом обратной связи между ними.
Под влиянием объективной потребности создавать программы быстрее возникла методология Agile. Она значительно изменила положение дел: цикл разработки сократился и стал более гибким. Появилось понятие «спринт» с короткими частыми итерациями.
Поскольку скорость создания продукта стала конкурентным преимуществом, привычный подход с разделением разработки, эксплуатации и тестирования несколько устарел. Поэтому появился подход DevOps, который устранил это разделение с помощью инструментов автоматизации. Сегодня эти границы стерлись еще сильнее: появился DevSecOps, включающий в общую команду еще и специалистов по безопасности. Теперь командам разработчиков нужно думать не только о создании фич, но и том, чтобы после релиза они работали правильно, эффективно и в соответствии с актуальными стандартами безопасности. Используя тесно связанные друг с другом Shift-left testing и автоматизацию тестирования, можно и дальше создавать инновации, в сжатые сроки разрабатывать высококачественный софт и соблюдать все требования к разработке ПО.
Shift-left testing и микросервисы
Но недостаточно просто решить учитывать в работе вопросы безопасности и удобства пользователей. Нужны подходящие инструменты автоматизации, только тогда получится опробовать эти приемы работы и по мере необходимости масштабировать их в компании.
С точки зрения процесса в ходе внедрения методологии Shift-left testing в микросервисном стеке нужно решить три ключевых задачи:
- Каждый микросервис создается и работает отдельно от других. Это повышает скорость разработки, но необходимо применять методы и процессы Shift-left testing к каждому из этих компонентов по отдельности.
- Благодаря микросервисам разработчики могут выбирать наиболее подходящие языки программирования и зависимости от служб для решения поставленных задач. Эта гибкость и децентрализация достигаются с помощью внедрения приемов Shift-left testing для разных языков программирования и зависимостей.
- Важную роль играет и тестирование каждого микросервиса в контексте всего стека. Чтобы убедиться, что микросервис работает в целом как задумано, обычно используют разные виды тестов: интеграционные, комплексные, тесты производительности и т. п. Такое тестирование особенно трудно в контексте микросервисной архитектуры из-за сложности общей среды приложения.
У разных микросервисов и репозиториев разные пайплайны SDLC
Масштабирование пайплайнов
Чтобы решить первую и вторую из трех проблем, важнее всего выбрать правильную систему рабочих процессов и реализацию DevOps-пайплайна. Для бэкенда, написанного на Golang, и JavaScript-фронтенда, на которых выполняются разные микросервисы, этапы тестирования и виды тестов на каждом этапе будут разными. Для этого командам разработчиков нужен процесс, с которым просто иметь дело. И добавлять приемы Shift-left testing нужно с учетом специфики конкретного микросервиса и языка программирования.
Современные инструменты работы с пайплайнами, опирающиеся на приемы GitOps, например GitHub Actions, — шаг вперед на пути к идеалу. Для микросервиса каждой команды на уровне конфигурации выполняется настройка всего пайплайна, с которым может работать команда разработчиков. А междисциплинарные вопросы типа инфраструктуры тестирования остаются на усмотрение команд DevOps.
В рамках идеологии Shift-left testing команда может интегрировать и автоматизировать в DevOps-пайплайн такие виды тестов, как статический анализ и анализ кода, модульные, интеграционные тесты, тесты производительности, безопасности и т. п. Учитывая разнообразие микросервисов, нужна такая система пайплайнов, в которой их легко создавать, а с ними просто работать. Тогда эти задачи сможет взять на себя преимущественно сама команда разработчиков с минимальным руководством со стороны DevOps и команды по развитию платформы.
Тестовая среда
Для интеграционных тестов, тестов производительности и некоторых других классов тестовая среда играет ключевую роль. Среда — это изолированный набор микросервисов и конфигурация, в которой выполняется тестирование. Характер и качество среды имеют непосредственное значение для методов Shift-left testing и его эффективности.
Когда масштабы и уровень сложности относительно невелики, можно создать тестовую среду, клонировав всю промежуточную или продакшен-среду. Однако когда организация достигает порога в тысячи микросервисов, стоимость инфраструктуры и техобслуживания традиционной тестовой среды значительно возрастает.
В результате на начальных этапах SDLC выполняются только некоторые базовые тесты состояния и Mock-based-интеграционные тесты, а критически важное тестирование переносится на потом. Это помогает в краткосрочной перспективе, но вносит новые проблемы с сигналом о проведении и достоверностью теста. Из-за этого в конечном счете либо возникают трудности в промежуточной среде, либо падает качество программы. В следующей главе давайте рассмотрим возможное решение этой проблемы, которое проще масштабировать в микросервисной архитектуре.
Песочница
Когда компании пытаются масштабировать Shift-left testing, они часто сталкиваются с проблемой доступности высококачественной тестовой среды. В традиционном подходе для тестирования используются несколько выверенных промежуточных сред. В конечном счете они утрачивают стабильность и становятся узким местом системы, замедляя жизненный цикл разработки программ. В Signadot Sandboxes используют совершенно другой подход к тестовым средам. В отличие от традиционной среды, Sandboxes используют Multi-tenancy уровня приложения, обеспечивая одновременно и изоляцию, и совместный доступ к ресурсам. Каждая среда может использовать внешние зависимости облака, Hosted базы данных и т. п., а не их макеты, применяемые в традиционной среде.
Из всего стека сервисов тестовая микросервисная среда проверяет изменения всего в нескольких службах — их обычно не более трех.
Эти песочницы разгоняются за секунды и масштабируются до тысяч микросервисов. При таком подходе можно создать отдельную тестовую среду для Pull-request, ветви или даже коммита. При этом даже при масштабировании микросервисов не возникает неконтролируемого роста расходов на инфраструктуру или рабочей загрузки.
В высококачественной быстро разворачиваемой тестовой среде можно в изолированном режиме тестировать даже самые небольшие изменения. Это гарантирует высокую производительность, стабильность и корректность в контексте всех ее зависимостей. Песочница — важный инструмент, который может помочь компаниям на пути к Shift-left testing микросервисов.
Вы можете протестировать микросервисы и Kubernetes в облаке VK Cloud. Новым пользователям мы начисляем 3000 приветственных бонусов.
