Чем раньше, тем лучше: сдвигаем тестирование в начало разработки в среде Kubernetes

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру 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 в микросервисном стеке нужно решить три ключевых задачи:

  1. Каждый микросервис создается и работает отдельно от других. Это повышает скорость разработки, но необходимо применять методы и процессы Shift-left testing к каждому из этих компонентов по отдельности.
  2. Благодаря микросервисам разработчики могут выбирать наиболее подходящие языки программирования и зависимости от служб для решения поставленных задач. Эта гибкость и децентрализация достигаются с помощью внедрения приемов Shift-left testing для разных языков программирования и зависимостей.
  3. Важную роль играет и тестирование каждого микросервиса в контексте всего стека. Чтобы убедиться, что микросервис работает в целом как задумано, обычно используют разные виды тестов: интеграционные, комплексные, тесты производительности и т. п. Такое тестирование особенно трудно в контексте микросервисной архитектуры из-за сложности общей среды приложения.


У разных микросервисов и репозиториев разные пайплайны 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 приветственных бонусов.
Источник: https://habr.com/ru/companies/vk/articles/732996/


Интересные статьи

Интересные статьи

Привет, Хабр! Сегодня у меня для вас отличные новости. В последние несколько лет мы во «Фланте» внимательно следили за технологиями-лидерами в cloud-native. Но это вовсе не праздное любопытство: из ни...
Сегодня СУБД PostgreSQL является одной из самых известных и популярных систем управления баз данными в мире. Открытый исходный код, отсутствие платы за использование, контроль целостности, репликация ...
Надежда Филаретовна, баронесса фон Мекк, дама с железным характером, наконец-то убедила своего мужа Карла Федоровича оставить государственную службу, где он дослужился до подполковника Министерства пу...
В эпоху продуктовой разработки с постоянным использованием гибких методологий и «насаживанием» их везде (порой даже не к месту) хочется напомнить об одной из классических...
При чём тут лебедь? Если Вас, как CEO или CTO IT-проекта (быстрорастущего или уже крупного), не покидают ощущения, что: Roadmap продукта буксует Разработка не успевает з...