Привет, Хабр! На связи Кирилл Шувалов, 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 это только первый шаг в её дальнейшем развитии.
Теперь вам будет проще масштабировать и развивать свою систему!)
