Какое место занимает качество программного обеспечения в мире развертывания по несколько раз в день?

Один из лучших аспектов моей работы в качестве архитектора DevOps - это глубокое понимание бесчисленных приложений конвейера CI / CD, использующих все типы технологий, о которых вы только можете подумать.

Незадолго до того, как я взял отпуск по уходу за ребенком, я работал над новым приложением, которое было с нуля переписано и переархивировано для облака AWS с использованием микросервисной архитектуры. Вопрос номер один, который они задают, - Какое место занимает SQA в этом новом мире?.

Это отличный вопрос, потому что, похоже, в отрасли есть две крайности. С одной стороны, есть Call Of Duty: Warzone, который, кажется, развертывает новые обновления без единой проверки качества перед выпуском, доставляя игрокам сильную головную боль во всем мире. Напротив, есть группы, которые воздерживаются от практики непрерывной доставки для SQA, чтобы вручную развернуть и протестировать интерфейсное приложение.

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

Что SQA делала в прошлом?

Обеспечение качества программного обеспечения (SQA) - это традиционное групповое подразделение в рамках подразделения разработки программного обеспечения организации, которое выполняет сквозное тестирование программного продукта перед выпуском.

Один из самых известных примеров, сделанных полумейнстримом, был в популярном фильме Бабушкин мальчик. В фильме рассказывается о тестировщике видеоигр, который вынужден переехать к своей бабушке после того, как его выселили из дома. Этот фильм вышел в 2006 году - за 4 года до того, как я начал работать в ИТ. В фильме участвуют гениальный разработчик, который пишет невероятные видеоигры, и огромная команда тестировщиков, которая играет на разных уровнях и составляет отчеты об обнаруженных ими ошибках. Это не так уж и далеко от того, как это работает в реальной жизни.

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

  • Интеграционное тестирование
  • Сквозное тестирование
  • Тестирование производительности
  • 508 тестирование на соответствие
  • Тестирование поддержки браузера
  • Тестирование контракта API
  • Тестирование отказоустойчивости данных
  • Тестирование высокой доступности
  • Тестирование аварийного восстановления
  • Тестирование на проникновение
  • Тестирование безопасности / уязвимости

Это много испытаний! Конечно, некоторые из этих тестов выполняются вручную, но значительная часть автоматизирована.

Одной из самых больших проблем является необходимость тестирования в стабильной среде, в то время как разработчики могут постоянно разрабатывать новые функции и развертывать их через среды DEV и QA. Если развертывание происходит в середине теста, это может или не может нарушить тест, но в любом случае оно аннулирует результаты, так как код изменился.

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

Я считаю это анти-шаблоном - нам не нужно обновлять весь наш стек с манифестом, чтобы решить проблему тестирования.

Провал SQA и Agile

SQA, по сути, был написан из мира Agile, DevOps и непрерывной доставки. Вместо этого организации предпочли, чтобы разработчики сами писали тесты, чтобы эти тесты проходили во время CI и, если да, их можно было развернуть. Это отличная практика, соответствующая принципу «сдвиг влево», позволяющий разработчикам иметь больший контроль над кодом, который они пишут. Однако в этой модели полностью отсутствуют два важных компонента пирамиды тестирования:

  • Интеграционное тестирование
  • Сквозное тестирование

Вернемся к примеру «Бабушкин мальчик». Это проявляется в том, что код доставляется без подтверждения того, что новый код работает с существующим.

Что еще больше усугубляет проблему при использовании микросервисной архитектуры, что именно диктует необходимость сквозного тестирования? Когда микросервисы предназначены для изолированного создания и развертывания, как и где может применяться сквозное тестирование?

Это отличные вопросы, поэтому позвольте мне предложить несколько различных подходов к их решению.

Развертывайте высококачественный код в мире гибкой разработки

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

Вот три стратегии, которые могут это обеспечить.

Эфемерные среды

Первая проблема с текущей архитектурой этого приложения заключается в том, что они статически определили DEV и QA среду, даже если они находятся в облаке. Я не обязательно виню их, потому что определение набора сред для продвижения кода - это разработка корпоративного программного обеспечения 101.

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

Команды проделали отличную работу, описав свою инфраструктуру как код с Terraform, но они сделали это с учетом этих статических сред.

Решение? Войдите в GitOps и среды, определенные с помощью стандартной ветки GIT. Так как же это на самом деле выглядит?

Если вы используете GITFLOW, то идеальным вариантом будет стандартизация соглашения об именах и тегах для развертываний и их привязка к среде. Вот пример:

Во-вторых: извлеките переменные среды из вашей инфраструктуры как кода и вместо этого передайте их во время CI, которое запускается на основе вашей ветки / тега, например:

Непрерывный мониторинг

Для одного из облачных приложений, запущенных в производство, мониторинг был запоздалым. Что вы отслеживаете в бессерверном приложении? Как мы узнаем, что наше приложение не работает, а не микросервис?

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

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

Стратегии развертывания

Как уже упоминалось, QA и разработчики часто сталкиваются с необходимостью получения хороших результатов тестирования и необходимости постоянного развертывания исправлений в подготовительных средах. Однако при развертывании в производственной среде мы знаем, что пользователи, вероятно, будут находиться в разных частях нашего приложения. Никогда не будет «стабильного состояния», поэтому мы можем принять хаос с точки зрения SQA и переключить наше внимание на непрерывное тестирование.

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

Например, мой интерфейс создает новый экран для поиска чего-либо. Изменения в моем проекте angular должны пройти три 508 автоматизированных цикла тестирования плюс один тест браузера для всех поддерживаемых браузеров, прежде чем код можно будет объединить в master и развернуть.

Это дает интересный поворот в развертывании. Вы больше не проходите / не проходите один набор тестов по сравнению с одной версией, теперь вы используете шкалу достоверности / риска для развертывания.

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

Заключение

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

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

Спасибо за прочтение!