Внутренний сервис по подготовке и настройке виртуального окружения и инфраструктуры

Если вы когда-нибудь пользовались облачными платформами вроде Amazon или Azure, чтобы создавать там виртуальные машины для тестов и работы, вы знаете насколько это удобно. Один из топовых банков РФ принял решение внедрить внутри IT подразделений собственное программное обеспечение, которое на базе внутреннего дата центра и серверных кластеров позволит создать собственный внутренний сервис по подготовке и настройке виртуального окружения и инфраструктуры.

Нашей команде выпала честь участвовать в этом проекте с самого начала (еще до реализации MVP) и довести этот сервис до интеграции с единой облачной инфраструктурой банка и другими его внутренними сервисами.

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

Наша команда работала над этим проектом с самого его старта и довела до полной интеграции с основной системой. Это был очень интересный опыт на стыке системного администрирования и девопс, тестирования и аналитики.

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

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

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

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

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

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

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

В ходе проведения тестирования на ранних этапах были выявлены многие проблемные места в архитектуре и корневом функционале компонентов. Анализ позволил исправить их на начальных этапах разработки.

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

Благодаря тому что с первых недель работы на проекте применялись повышенные требования к качеству технической документации и входным требованиям и предлагаемым архитектурным решениям, уже на этапе MVP разрабатываемый сервис имел лишь 12% кодовой базы, которая была в последствии переработана.

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