Привет, Хабр! На связи Кирилл Шувалов, Senior QA Test Engineer аутстаффинговой компании Smart IT. Сегодня мы поговорим с вами о том, как перенести вашу промышленную систему в кластер OpenShift бесшовно для заказчика/конечного пользователя, работая в методологии Agile и не надорваться в процессе.  Давайте немного обрисуем проблему: вы развиваете свою систему, уходите от монолитных сервисов в сторону более гибкой микросервисной архитектуры. В какой-то момент состояния системы между двумя/тремя монолитами и кучей микросервисов, вы понимаете, что жить вашей системе на физических серверах становится сложнее. Сложнее следить за состоянием модулей, перезапускать их, при необходимости, и распределять нагрузку, если есть дублирование. На это требуется всё больше ресурсов сотрудников вашей команды. Или требования вашей enterprise компании к надёжности внутренних систем предусматривают переход на микросервисную архитектуру с дублированием ключевых или всех сервисов. Так или иначе, перед вашей командой ставится задача перевода вашего продукта под управление OpenShift. И сделать это ваша agile-команда должна быстро, например, за квартал. В одиночку ваша команда этого сделать не сможет из-за нехватки штата agile-команды и необходимых специалистов. Нужна помощь команды DevOps по настройке и развёртыванию вашей системы на dev и prod средах. Для вашей команды “всего-навсего” остаётся полноценное поддержание жизненного цикла системы и дальнейший перевод на микросервисную архитектуру. Нужны ресурсы аналитиков внутри вашей команды или сторонние аналитики, которые будут создавать и утверждать архитектуру вашей будущей системы “SystemName” 2.0. Итак, для успешного вывода системы в OpenShift вам понадобятся:  Команда DevOps — для подготовки кластера OpenShift; TeamLead — для постановки целей и сроков; Аналитики — для разработки архитектуры и её согласования; Разработчики — кто-то же должен пилить новые фичи и готовить систему для перевода в OpenShift; Тестировщики —  “Фигаро тут, Фигаро там”. Аналитики создают новую архитектуру, разработчики продолжают пилить новые фичи, продакт/тимлид извергает пар из ушей. В целом, ничего нового. А что делает тестирование? А у тестирования своя головная боль. Методология agile предполагает частые поставки нового функционала заказчику. Вывод вашей системы на новые технологии дело несомненно нужное, но фичи для заказчика никто не отменял. А это значит, что тестированию предстоит проверять новые доработки на двух различных вариантах системы: на условно старой версии системы, когда система была развёрнута на серверах, и условно новой версии, когда система будет развёрнута в кластере OpenShift. В целом, такое важное событие в процессе тестирования, как переезд в Openshift, мало чем отличается от обычного рабочего процесса, разве что нагрузкой и требованиями к компетенциям. Просто необходимо проводить тестирование на ещё одном контуре где развёрнута ваша система в OpenShift, который поддерживает смежная команда DevOps. Для тестирования появляется необходимость в изучении новых технологий, например:  Контейнеры и их жизненный цикл; Взаимодействие с консолью управления кластером OpenShift; Навыки конфигурации и сборки/перезапуска экземпляров сервисов; Понимание принципов микросервисной архитектуры; Протоколы взаимодействия между микросервисами и со сторонними системами (Kafka, gRPC, WebSocket, REST); Итак, ваши тестировщики заранее (я на это очень надеюсь) изучили новую для себя технологию и имеют представление, как и что тестировать. Команда DevOps подготовила кластер и сконфигурировала инструменты для автоматизированного диплоя. Для полного перехода в OpenShift необходимо будет выровнять релизы, передающееся на сервера и на кластер. Что я подразумеваю под “выровнять”? Это значит, что тестированию придётся проверять новые фичи для ПРОМа на физических серверах и параллельно проверять как работают уже выпущенные релизы на новой архитектуре. А разработка будет исправлять дефекты, которые обязательно появятся на новой архитектуре. И это будет продолжаться до тех пор, пока ваша команда не перейдет полностью на новую архитектуру и не продолжит релизный цикл уже на ней. Давайте разберем этот процесс по шагам.  Шаг 1. Полный регресс системы после переноса в OpenShift. Будет здорово, если у вас уже есть автоматизация регресса основного функционала; Шаг 2. Параллельное тестирование текущего релиза на “железные” сервера и отстающее на 2-3 релиза тестирование функционала в OpenShift; Шаг 3. На протяжении нескольких спринтов постепенно догонять релизы выпускаемые на “железные” сервера;   Шаг 4. Параллельный релиз системы сразу на пром двумя разными архитектурными решениями вашей системы; шаг 5. Поэтапный перевод нагрузки с системы со старой архитектурой на новую; Шаг 6. Доработка системы на новой архитектуре согласно требованию заказчика,  это же Agile; Шаг 7. Полный отказ от системы на старой архитектуре и переход на новую.  И вот, спустя множество переходов от шага к шагу по возрастанию и убыванию, ваша система наконец-то переехала в OpenShift. Заказчик не замечает разницы между старой архитектурой и новой, а это главное. Значит ваш переезд произошёл успешно и бесшовно. Впереди у ваших аналитиков ещё много работы, поскольку переезд вашей системы в OpenShift это только первый шаг в её дальнейшем развитии. Теперь вам будет проще масштабировать и развивать свою систему!)