Привет, Хабр! На связи Кирилл Шувалов, 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, мало чем отличается от обычного рабочего процесса, разве что нагрузкой и требованиями к компетенциям. Просто необходимо проводить тестирование на ещё одном контуре где развёрнута ваша система в OpenShift, который поддерживает смежная команда DevOps. Для тестирования появляется необходимость в изучении новых технологий, например:

• Контейнеры и их жизненный цикл;

• Взаимодействие с консолью управления кластером OpenShift;

• Навыки конфигурации и сборки/перезапуска экземпляров сервисов;

• Понимание принципов микросервисной архитектуры;

• Протоколы взаимодействия между микросервисами и со сторонними системами (Kafka, gRPC, WebSocket, REST);

Что дальше?

Итак, ваши тестировщики заранее (я на это очень надеюсь) изучили новую для себя технологию и имеют представление, как и что тестировать. Команда DevOps подготовила кластер и сконфигурировала инструменты для автоматизированного диплоя. Для полного перехода в OpenShift необходимо будет выровнять релизы, передающееся на сервера и на кластер.

Что я подразумеваю под “выровнять”? Это значит, что тестированию придётся проверять новые фичи для ПРОМа на физических серверах и параллельно проверять как работают уже выпущенные релизы на новой архитектуре. А разработка будет исправлять дефекты, которые обязательно появятся на новой архитектуре. И это будет продолжаться до тех пор, пока ваша команда не перейдет полностью на новую архитектуру и не продолжит релизный цикл уже на ней. Давайте разберем этот процесс по шагам.

Релизный цикл

Шаг 1. Полный регресс системы после переноса в OpenShift. Будет здорово, если у вас уже есть автоматизация регресса основного функционала;

Шаг 2. Параллельное тестирование текущего релиза на “железные” сервера и отстающее на 2-3 релиза тестирование функционала в OpenShift;

Шаг 3. На протяжении нескольких спринтов постепенно догонять релизы выпускаемые на “железные” сервера; 

Шаг 4. Параллельный релиз системы сразу на пром двумя разными архитектурными решениями вашей системы;

шаг 5. Поэтапный перевод нагрузки с системы со старой архитектурой на новую;

Шаг 6. Доработка системы на новой архитектуре согласно требованию заказчика,  это же Agile;

Шаг 7. Полный отказ от системы на старой архитектуре и переход на новую. 

Итог

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

Теперь вам будет проще масштабировать и развивать свою систему!)