6 способов деплоя веб-приложений
Деплой — это процесс развертывания веб-приложения или сайта в рабочей среде: на гостевом хостинге или сервере. Разбираемся, какие есть способы деплоя, в чем их преимущества и недостатки, а также какой из них выбрать в разных ситуациях.
Если вы еще не знаете, что такое деплой и как его проводить, сначала прочитайте наш гайд, а потом возвращайтесь к статье.
Повторное создание
Способ, при котором разработчик сначала отключает старую версию приложения (V1 на картинке), а затем развертывает новую версию (V2 на картинке). При этом в работе приложения возникает перерыв, длительность которого зависит от скорости отключения и повторного запуска.
- Простота
- Состояние приложения полностью обновляется.
- Пользователь не может использовать сервис во время простоя, длительность которого зависит от скорости проведения работ.
Последовательное развертывание
Разработчики постепенно заменяют экземпляры текущей версии приложения на экземпляры новой версии. Процедура выглядит следующим образом: балансировщик нагрузки распределяет трафик между серверами в пуле экземпляров версии V1. Потом развертывается один экземпляр версии V2. Когда новый экземпляр готов принимать трафик (пользователей, которые заходят в приложение), его включают в пул. Затем удаляют и отключают один экземпляр версии V1.
Чтобы увеличить время развертывания, можно изменять эти максимальные значения:
- Количество экземпляров, которые развертываются одновременно
- Увеличение количества экземпляров во время деплоя
- Количество экземпляров, недоступных во время последовательного развертывания.
- Простота
- Экземпляры приложения заменяются постепенно
- Удобно перераспределять данные приложений, сохраняющих информацию о запросах.
- Развертывание и откат к предыдущей версии занимают много времени
- Сложно реализовать поддержку нескольких API
- Отсутствует контроль за трафиком.
Освойте DevOps на интенсиве Хекслета Научитесь автоматизировать окружение, деплоить приложения одной кнопкой одновременно на любое количество машин и разворачивать облачный кластер на Digital Ocean или Yandex Cloud.
Сине-зеленый деплой
Сине-зеленый деплой означает, что синяя версия V2 развертывается параллельно зеленой версии V1 с одинаковым количеством экземпляров. Убедившись, что новая версия работает исправно, разработчики перенаправляют трафик от версии V1 к версии V2 с помощью балансировщика нагрузки.
- Моментальное развертывание и откат
- Так как приложение развертывается целиком, не возникают проблемы из-за одновременного использования двух версий.
- Высокая стоимость, так как для такого деплоя требуется вдвое больше ресурсов
- Перед развертыванием нужно тщательно протестировать платформу
- Сложно работать с приложениями, сохраняющими данные о запросах.
Канареечный релиз
Канареечный релиз позволяет постепенно перенаправить трафик от версии V1 к версии V2. Обычно трафик распределяется пропорционально: например, 90% запросов отправляется версии V1, а 10% — версии V2.
Этот метод используется, если тестов не хватает, или они не дают надежные результаты. Еще он подходит, когда разработчики не уверены в стабильности новой версии.
- Версия доступна части пользователей
- Удобно отслеживать коэффициент ошибок и работу новой версии
- Быстрый откат.
- Медленное развертывание.
A/B-тестирование
Пользователи, которые отвечают заранее определенным условиям, получают доступ к новым функциям. Этот метод похож на стратегию канареечного релиза, но отличается целями. A/B-тестирование — это не только стратегия деплоя, но и способ принятия бизнес-решений на основании статистики. Часто этот способ используется, чтобы оценить эффект изменения и определить, какая версия больше нравится пользователям.
Трафик может распределяться на основании следующих условий:
- Настройки файлов cookie
- Параметры запросов
- Геолокация
- Браузер, размер экрана, ОС и другие технические характеристики
- Язык.
- Параллельная работа нескольких версий
- Полный контроль над распределением трафика.
- Требуется умный балансировщик нагрузки
- Сложно устранять проблемы для конкретного сеанса
- Требуется трассировка распределенных систем.
Скрытое развертывание
Версия V2 развертывается параллельно версии V1. Она тоже получает входящие запросы, но не влияет на реальный трафик. Так можно протестировать нагрузку новой функции. Полный переход на новую версию происходит, когда приложение работает стабильно и отвечает требованиям.
Это сложная стратегия с дополнительными требованиями, которая использует исходящий трафик. Иногда из-за этого возникают ошибки: например, если интернет-магазин проводит скрытое тестирование платежного сервиса, клиент может случайно оплатить заказ дважды. Чтобы этого избежать, придется создать сервис, который имитирует ответ поставщика услуг.
- Работа приложения проверяется на основе реального трафика
- Пользователь не теряет доступ к приложению
- Приложение развертывается только тогда, когда оно отвечает всем требованиям заказчика.
- Высокая стоимость, так как требуется вдвое больше ресурсов
- Результаты могут вводить в заблуждение, поскольку полноценный пользовательский тест не проводится
- Сложность организации
- В некоторых случаях требуется сервис для имитации услуг.
Какую из стратегий деплоя использовать
Выбор стратегии деплоя зависит от потребностей и бюджета. Например, для развертывания на этапе разработки или в промежуточной среде подходит повторное создание или последовательный деплой. Для выпуска готовой версии приложения используется последовательное или сине-зеленое развертывание, но только после проведенного тщательного тестирования.
Сине-зеленое развертывание и скрытый деплой стоят дороже, так как требуют вдвое больше ресурсов. Если тестирование не проводится в нужном объеме, или есть сомнения в отношении функционирования и стабильности приложения, подойдет канареечный релиз, A/B-тестирование или скрытое развертывание. Чтобы протестировать новую функцию на группе пользователей, можно применить фильтр, используя такие параметры, как геолокация, язык, ОС или настройки браузера. Для этого применяют A/B-тестирование.
Скрытое развертывание — сложная и трудоемкая стратегия. Если приложение работает с внешними зависимостями и отправляет выходной трафик почтовым сервисам, банкам или другим партнерам, такие действия требуется имитировать. Однако эта стратегия полезна при переходе на новую базу данных и использовании теневого трафика для мониторинга работы под нагрузкой.
Эта статья — адаптированный перевод материала разработчика Этьена Тремеля, опубликованного в блоге The New Stack.
Canary Releases
Метод снижения риска внедрения новой версии программного обеспечения в “производственную среду”. Происходит путем плавного развертывания изменений для небольшой группы пользователей.
Отрывок из блога Мартина Фаулера
Откуда такой термин?
Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.
В чем основная суть метода?
Новый функционал или его обновлённая часть публикуется для ограниченной аудитории по мере готовности на продакшен окружение. Перед деплоем достаточно убедиться, что код не содержит синтаксических ошибок. Этот шаг может быть частью ci пайплаина. Первые пользователи, которые увидят изменения, могут быть разработчиками или тестировщиками. После проверки функционала, который уже находится в той среде, где с ним начнут взаимодействовать реальные пользователи, можно открыть доступ настоящим пользователям частично или полностью. В случае нахождения ошибок фичу можно моментально закрыть от пользователей и минимизировать потери (репутационные, финансовые).
Альтернативный способ?
Использовать предпродакшен среду, на которую сначала публикуются изменения, после этапа проверки и тестирования. Изменения попадают в продакшен среду, где еще раз проверяются на ошибки связанные с интеграцией, которые могли возникнуть из за неточности двух окружений.
Какие плюсы у канареечного релиза?
- Отпадает необходимость держать лишние окружения: экономия времени разработчиков на поддержку актуального состояния тестовой среды.
- Снижение финансовых затрат на n-ое количество тестовых окружений.
- Тестирование происходит сразу на продакшен среде — выявляются ошибки интеграции, которые могут не возникать на тестовом окружении.
- Позволяет перейти на Trunk-Based Development(Patterns for Managing Source Code Branches) — подход, когда в системе контроля версий используется одна ветка, в которую сразу попадает весь написанный код. Такой подход избавляет разработчиков от затрат времени на решение больших и сложных конфликтов в коде. А так же исключает ситуацию, когда уже реализованный функционал где-то теряется 🙂
- Бонусом появляется возможность проводить A/B тесты на пользователях и находить лучшее решение, а также быстро проверять гипотезы.
- Возможность демонстрации заказчику будущих изменений сразу на продакшен окружении.
- Ранний доступ для лояльных пользователей и сбор обратной связи позволяют узнать как воспримут будущие изменения реальные пользователи.
- Если есть разные платформы (andord, ios, web) — одновременно для пользователей всех платформ предоставить доступ к новому функционалу — единовременный релиз.
- Культура децентрализованного принятия решений — принимать решения на основе продуктовых или технических метрик. Например, автоматизировать откат новой фичи в случае аномального роста нагрузки после релиза.
Какие накладные расходы для использования канареечных релизов?
- Разработчик должен гарантировать, что его код не содержит синтаксических ошибок и способен запуститься. Решается успешной компиляцией или использованием статического анализатора кода для интерпретируемых языков перед поставкой кода в продакшен среду.
- Использование готового или разработка своего механизма переключения доступа к фичам — Feature Toggles (aka Feature Flags)
Почему стоит использовать канареечные релизы?
Масштабирование, снижение количества ошибок, автоматизация ручной работы. При ускорении time to market и увеличении количества релизов ограничением становятся тестовые окружения, где в один момент времени может быть только одно изменение в тесте.
Фундаментальные проблемы нескольких предпродакшен окружений: при росте инфраструктуры и сложности приложения сложность поддержки тестовых окружений будет расти, увеличивая стоимость поддержки окружения и снижая частоту релизов. Тестовое окружение не может быть идентичным продакшен, а пользовательский трафик не может быть сопоставим.
Полезные материалы:
- Canary release — блог Мартина Фаулера
- Feature Flags, Toggles, Controls — библиотека для фичтоглинга
- Тестируем на проде: Canary Deployment
- The Facebook Mobile Release Process — видео с доклада
- Facebook — Rapid release at massive scale
- Automated Canary Analysis at Netflix with Kayenta
Deployment
При этой стратегии создается полная копия инфраструктуры (Green) для новой версии приложения, а затем постепенно перенаправляется трафик на нее, оставляя предыдущую версию (Blue) работающей параллельно. Это обеспечивает возможность быстрого отката в случае проблем и минимизирует риски простоя системы.
Одна из задач автоматизации деплоя — переход из одного состояния в другое внутри себя же, с переводом софта из финальной стадии тестирования в действующий продакшен. Обычно это нужно сделать быстро, чтобы минимизировать время простоя. При сине-зеленом подходе у вас есть два продакшена, насколько возможно идентичных. В любое время один из них, допустим синий, активен. При подготовке новой версии софта, вы делаете финальное тестирование в зелёном продакшене. Вы убеждаетесь, что программа в этом продакшене работает и настраиваете роутер так, чтобы все входящие запросы шли в зелёную операционную среду — синяя в режиме ожидания.
Сине-зелёный деплой также даёт вам возможность быстро откатиться до старого состояния: если что-то пойдет не так, переключите роутер обратно на синий продакшен. Но вам всё ещё придётся справляться с пропущенными транзакциями, пока зелёный продакшен активен, и, в зависимости от структуры кода, вы сможете направлять транзакции в оба продакшена, чтобы сохранять синий как резервную копию, при активном зелёном. Или можете перевести приложение в read-only режим, перед синхронизацией, запустить его на время в этом режиме, а потом переключить в режим read-write. Этого может оказаться достаточно, чтобы избавиться от многих нерешенных проблем.
Canary Deployment (канареечные релизы)
При этой стратегии новая версия приложения запускается на ограниченной части инфраструктуры или для небольшого числа пользователей, чтобы проверить его работоспособность и сравнить с предыдущей версией. Если новая версия проходит проверку успешно, она постепенно внедряется на остальные серверы или для всех пользователей.
Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.
При использовании этого шаблона, когда мы делаем выпуск, то наблюдаем, как программное обеспечение работает в каждой среде. Когда что-то кажется неправильным, мы выполняем откат, в противном случае мы выполняем развертывание в следующей среде.
Blue-Green-Canary Deployment
Это комбинированная стратегия, объединяющая элементы Green-Blue и Canary деплоя. При этом создается новая версия (Blue), которая постепенно внедряется на ограниченный набор серверов или пользователей (Canary). После проверки и удовлетворения результатами, новая версия становится основной (Green), а предыдущая версия сохраняется в качестве резервной.
Shadow Deployment (теневой)
При данной стратегии новая версия приложения запускается параллельно с текущей активной версией, но не обрабатывает реальные запросы пользователей. Вместо этого, она получает копии запросов и используется для сбора данных о производительности и стабильности новой версии без риска негативного влияния на пользователей.
Rolling Deployment (плавный деплоймент)
Эта стратегия предусматривает постепенное обновление приложения или инфраструктуры путем замены старых компонентов новыми на протяжении определенного времени или количества этапов. Это позволяет распределить нагрузку и снизить риски, так как если что-то идет не так, можно быстро вернуться к предыдущей версии.
A/B Testing (A/B тестирование)
Эта стратегия предполагает разделение пользователей на две группы: одна получает новую версию приложения (группа A), а другая продолжает использовать предыдущую версию (группа B). Это позволяет сравнить производительность, стабильность и пользовательский опыт между версиями и принять решение о полном переходе на новую версию.
Feature Toggles (фич-тоглы)
Эта стратегия позволяет включать и отключать определенные функциональные возможности приложения в зависимости от конфигурации. Таким образом, можно поэтапно вводить новые функции или экспериментировать с разными вариантами, не влияя на работу основного приложения.
Traffic Splitting (разделение трафика)
При этой стратегии трафик распределяется между несколькими версиями приложения в определенных пропорциях. Это позволяет постепенно увеличивать нагрузку на новую версию и наблюдать ее работу в реальном времени, а также сравнивать ее с предыдущей версией.
Immutable Infrastructure (неизменяемая инфраструктура)
Эта стратегия предполагает создание инфраструктуры, которая не подвергается изменениям после развертывания. Вместо этого, для обновления приложения создается новая инфраструктура с новой версией приложения, что обеспечивает простоту отката и предотвращает проблемы, связанные с изменениями в рабочей инфраструктуре.
Blue-Green-Red Deployment
Это расширенная версия Blue-Green деплоя, в которой предусмотрено наличие третьей окружения (Red), используемого для разработки и тестирования новых функций. При этом Blue и Green окружения остаются стабильными и готовыми к использованию, а Red используется для экспериментов и разработки.
Список стратегий деплоя
- Green-Blue Deployment
- Canary Deployment
- Rolling Deployment
- A/B Testing
- Blue-Green-Canary Deployment
- Shadow Deployment
- Feature Toggles
- Traffic Splitting
- Immutable Infrastructure
- Blue-Green-Red Deployment
- Rolling Updates
- Recreate Deployment
- Traffic Mirroring
- Dark Launching
- Forking
- Phased Rollout
- Ring Deployment
- Delta Deployment
- Staged Rollout
- Live Migration
- Binary Delta Deployment
- Hybrid Deployment
- Multi-Armed Bandit
- Traffic Shifting
- Zero Downtime Deployment
- Chaos Engineering
- Parallel Deployment
- Incremental Deployment
- Strangler Pattern
- Hot Patching
Что такое канареечное тестирование (Сanary Testing)?
Канареечное тестирование – проверка новой версии приложения или новой функции с реальными пользователями в реальной среде. Это происходит путем распространения некоторых изменений кода приложения среди небольшой группы конечных пользователей, которые обычно не знают об этом.
Поскольку новый код распространяется только на небольшое количество пользователей, его влияние относительно невелико. Более того, изменения можно быстро откатить, если новый код окажется ошибочным или вызовет проблемы у пользователей. Канареечное тестирование также известно как “канареечное развертывание” или “канареечный релиз”.
Содержание:
- Определение канареечного тестирования
- Почему канареечное тестирование эффективно?
- Как работает канареечное тестирование?
- Планирование канареечного развертывания
- Выполнение канареечного развертывания
- Анализ канареечного развертывания
- Преимущества канареечного тестирования
- Недостатки канареечного тестирования
- Другие методы тестирования изменений в ПО
Определение канареечного тестирования
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Слово “канарейка” описывает внедрение программного кода для определенного числа реальных конечных пользователей. Этот термин возник в связи с добычей угля и фразой “канарейка в угольной шахте”. Канарейки обладают меньшей, чем люди, устойчивостью к токсичным газам, поэтому их использовали для оповещения шахтеров, когда эти газы достигали опасного уровня в шахте.
При канареечном тестировании небольшая группа конечных пользователей выступает в качестве тестовой группы. Подобно канарейке в угольной шахте, эти пользователи не знают, какую роль они играют в обнаружении проблем в приложении.
Если изменения в коде вызывают проблемы, программа мониторинга оповещает команду разработчиков, чтобы они могли исправить код до того, как он будет выпущен для более широкой группы пользователей.
Почему канареечное тестирование эффективно?
Канареечный релиз – это хороший способ внедрять изменения в код, которые связаны с добавлением новых функций или созданием новой версии программного обеспечения. Это позволяет команде разработчиков быстро оценить, обеспечивают ли изменения в коде желаемые или ожидаемые результаты.
Канареечное тестирование также позволяет разработчикам попробовать новую функциональность приложения на небольшой группе пользователей. Благодаря тому, что в данном тестировании задействована лишь часть пользователей, влияние потенциальных проблем, связанных с новым функционалом, сводится к минимуму. Разработчикам проще откатить изменения и не допустить влияния ошибок новой версии приложения на всех пользователей.
Как работает канареечное тестирование?
Как и другие виды тестирования программного обеспечения, канареечное тестирование проводится по систематическому, пошаговому принципу. Ниже перечислены шаги, необходимые для проведения канареечного тестирования:
Шаг 1. Команда разработчиков выбирает пользователей в качестве тестовой команды. Эта группа представляет собой небольшое количество пользователей, но достаточное, чтобы получить результаты, позволяющие провести полноценный статистический анализ. Пользователи не знают о том, что они являются частью группы тестирования.
Шаг 2. Команда создает тестовую среду, которая работает параллельно с текущей рабочей средой. Они также настраивают балансировщик нагрузки системы так, чтобы пользовательские запросы направлялись в новую среду.
Шаг 3. Разработчики проводят канареечное тестирование, направляя запросы отобранных пользователей в новую среду. Они также наблюдают за пользователями в течение определенного времени, чтобы убедиться, что новая версия приложения работает в соответствии с ожиданиями.
Шаг 4. Если новая версия соответствует ожиданиям, то новый функционал или версия программного обеспечения может быть выпущена для всех пользователей. Однако если окажется, что новая версия приложения содержит много ошибок, плохо работает или создает другие проблемы для пользователей, то тестировщики возвращаются к исходной версии программного обеспечения.
Шаг 5. Команда устраняет обнаруженные ошибки и затем выпускает приложение для более широкой аудитории.
Планирование канареечного развертывания
Планирование канареечного развертывания включает в себя следующие факторы:
Количество пользователей и этапов. Общее количество пользователей, которые получат канареечное развертывание, и количество этапов – важные факторы, которые необходимо учитывать при планировании канареечного тестирования. Обычно в этом процессе задействовано 5% или 10% от общего числа пользователей. В некоторых случаях команда разработчиков выбирает группу “тестовых” пользователей на основе определенного географического региона.
Сроки/продолжительность. Канареечное тестирование может длиться как несколько минут, так и несколько часов, в зависимости от приложения и тестируемого кода. При планировании канареечного развертывания важно учитывать время, необходимое для всех аспектов тестирования.
Критерии оценки. Как и при любом другом виде тестирования ПО, успех или неуспех канареечного тестирования можно определить только в том случае, если предварительно определены критерии оценки.
Метрики производительности. Для анализа хода тестирования, оценки производительности приложения, определения загрузки процессора и памяти, а также отслеживания ошибок, необходимо собирать метрики.
Выполнение канареечного развертывания
После завершения планирования команда разработчиков выполняет фактическое канареечное развертывание, отправляя новый код выбранной группе пользователей. Разработчики готовят файлы для развертывания и настройки, пишут необходимые части кода и скрипты для тестирования.
Далее команда создает канареечный узел, используя процесс балансировки нагрузки, и делает копию настоящей рабочей среды. Для канареечного тестирования необходимы как минимум две рабочие среды, одна из которых будет представлять собой исходное приложение без изменений в коде.
Анализ канареечного развертывания
Когда новый код с изменениями отправляется к выбранной группе пользователей, это приводит к тому, что трафик идет и на базовые (обычные) узлы, и на тестовые узлы. Это позволяет команде разработчиков сравнить работу обеих версий и определить, соответствует ли тестируемая версия приложения ожиданиям, определенным на этапе планирования.
С помощью анализа логов можно выявить проблемы или ошибки, которые нужно исправить перед тем, как выпустить новую версию приложения для более широкой аудитории пользователей.
Преимущества канареечного тестирования
Канареечное тестирование позволяет легко проверить новую версию программного обеспечения или новую функцию в существующем приложении. Поскольку код с изменениями отправляется только небольшому числу пользователей, это значительно снижает риск ухудшения пользовательского опыта.
Кроме того, изменения или функции могут быть быстро отменены, если обнаружится, что они снижают производительность приложения, содержат ошибки или вызывают негативные отзывы у пользователей.
Канареечное тестирование – это хороший способ собрать полезную обратную связь от реальных пользователей перед важным обновлением в приложении. В некоторых случаях команда QA может быть первой группой, тестирующей новые функции. Они могут проводить тестирование в той же среде, что и конечные пользователи, чтобы найти ошибки, которые, возможно, не были обнаружены или выявлены в процессе тестирования.
Недостатки канареечного тестирования
Несмотря на то, что канареечное тестирование дает множество преимуществ командам разработчиков, оно имеет также и ряд недостатков. Например, сложно проводить канареечное тестирование мобильных приложений, поскольку существует только одна среда – персональное компьютерное устройство пользователя.
Одним из способов борьбы с этим ограничением является использование фича-флагов (feature flags), позволяющих удаленно включить ту или иную функцию только для небольшой группы пользователей.
Также полезно побудить конечных пользователей включить автоматическое обновление приложения, чтобы они получали регулярные обновления, которые позволят разработчикам легко провести канареечное тестирование.
Канареечное тестирование также может быть затруднено при быстром выпуске множества новых функций. Для тестирования всех этих функций потребуется несколько сред, управлять которыми может быть сложно. Фича-флаги – снова хороший способ решить эту проблему.
Канареечное тестирование требует использования нескольких компьютеров или серверов в рабочей среде, что делает процесс более сложным. Мониторинг работы новой системы также может быть трудоемким и требовать много времени, если выполняется вручную. Автоматизация позволяет снизить сложность и время, необходимое для анализа и исправления ошибок.
Средства автоматизированного тестирования также упрощают создание новых тестов и анализ результатов тестирования.
Другие методы тестирования изменений в ПО
Канареечное развертывание – это лишь один из методов обновления программного обеспечения. Существуют и другие методы развертывания обновлений ПО:
Базовая стратегия развертывания (Basic deployment strategy). Эта стратегия, известная также как “re-create”, предусматривает одновременное обновление всех систем новым программным обеспечением. Это самая простая стратегия развертывания, но и самая рискованная. Если обновление содержит ошибки, это затронет всех пользователей.
Стратегия инкрементного или “плавающего” обновления (Incremental or rolling update strategy). Она аналогична базовой стратегии развертывания, но при этом пользователи разбиваются на более мелкие группы, которые получают обновления поэтапно. Это позволяет в случае возникновения проблем приостановить релиз приложения до того, как он затронет всех пользователей.
Сине-зеленое развертывание (Blue-green deployment strategy). Сине-зеленое развертывание предполагает развертывание новой версии программного обеспечения наряду со старой версией. Оно требует вдвое больше ресурсов, чем стратегия инкрементного развертывания, и может привести к простою, в отличие от канареечного тестирования.
Однако этот метод позволяет уменьшить последствия выпуска некачественной версии ПО, так как пользователи могут быть быстро переключены на старую версию ПО. Кроме того, этот метод хорош в тех случаях, когда код был тщательно протестирован и ожидаемый риск неудачи считается низким.
A/B развертывание (A/B testing deployment). Этот метод используется для тестирования конкретных функций путем их развертывания для конкретных пользователей на основе определенных метрик.
Канареечное развертывание важно, но это не единственный правильный выбор для управления стратегиями развертывания. Узнайте больше о том, в каких случаях следует использовать канареечное развертывание, а в каких – синее/зеленое.
Похожие записи:
- Тестирование совместимости
- Кросс-браузерное тестирование
- Когда следует начинать нагрузочное тестирование?
- Как проводить backend тестирование