Клиент
Наш заказчик — крупная компания, предоставляющая финансовые сведения в области рынка, банковского дела, финансово-технологического и других секторов. Компания стремится автоматизировать процессы публикации, хранения и обогащения данных, а также совершенствовать обработку семантических метаданных. Кроме того, компании важно обеспечить пользователям максимально комфортный доступ ко всем её сайтам, размещённым под различными брендами, и возможность оперативно найти нужную информацию с помощью эффективных инструментов поиска.
Задачи
В течение многих лет в целях автоматизации процесса публикации заказчик пользовался различными внутренними программными продуктами и несколькими сайтами, имеющими общую базу. Как следствие, любые изменения этой базы могли повлечь за собой риски из-за тесной взаимосвязи всех компонентов. Кроме того, подход заказчика к разработке, сборке, развёртыванию и управлению пакетами и артефактами приводил к существенному замедлению всего процесса разработки.
Возникла необходимость выработки эффективного, масштабируемого подхода с возможностью проведения тестирования. На первом этапе работ выделились две задачи: разъединение элементов текущей инфраструктуры и настройка процесса разработки. Также следовало модернизировать систему авторизации, обновить хранилище контента и создать платформу для интеграции.
Решение
Процесс разработки
Работа с сервисно-ориентированным подходом предполагает изменение процесса разработки. Такая архитектура невозможна без стандартизации сервисных контрактов и соблюдения автономии сервисов. Каждый отдел отвечает за то, что вверенный ему сервис выполняет условия контракта, такие как доступность и низкий уровень ошибок. Приняв всё это во внимание, мы выделили следующие цели:
- определение границ каждого компонента программных решений;
- автоматизация процессов сборки и разработки;
- обеспечение возможности запуска сборок и развёртывания независимо друг от друга;
- создание чётких правил, регулирующих ответственность за определённый сервис или компонент.
Для выполнения последней задачи мы внесли изменения в систему контроля версий и процессы управления пакетами, сборки и разработки. В частности, был осуществлён переход на распределённую систему версионирования Git, где код, в отличие от централизованной системы SVN, хранится на множестве репозиториев.
Перевод управления зависимости на NuGet для приложений .NET и NPM для пакетов фронтенда был продиктован необходимостью следовать отраслевым стандартам. В результате мы получили два преимущества: приложения теперь могли зависеть от различных версий общедоступных библиотек, а настройка инструментов сборки и автоматизации стала намного проще, поскольку многие системы CI/CD поддерживают NuGet и NPM. Таким образом, уже имеющиеся пайплайны в TeamCity оказались более структурированными.
Процесс развёртывания, который ранее был автоматизирован лишь частично, мы полностью переработали с помощью Octopus Deploy. Это дало много преимуществ: например, воспроизводимое развёртывание, возможность сменить конфигурацию узла и проведение развёртывания практически без коммуникации между отделами.
Наконец, все отделы перешли на работу по методологии Scrum, что упростило обратную связь, обеспечило более быстрое выполнение задач и привело к постановке прогнозируемых целей и своевременной отчётности.
Рис. 1. Версионирование и развёртывание.
Подход к архитектуре
Ориентируясь на отраслевые стандарты, мы перевели систему авторизации на протокол OpenID Connect. Мы использовали open source библиотеку Identity Server, чтобы создать многоклиентскую архитектуру (один экземпляр приложения обслуживает несколько развёртываний), за счёт чего удалось обеспечить безопасное управление учётными данными заказчика.
На следующем этапе мы переработали некоторые внутренние проекты на основе сервисно-ориентированного подхода, в том числе развернули платформу управления контентом на базе ASP.NET WebAPI, Azure Storage и Azure API Management. Использование тем Azure Service Bus позволило пользователям заказчика получать уведомления об изменениях в документах, что сделало автоматизацию бизнес-процессов более простой, масштабируемой и асинхронной по умолчанию.
Для разделения процессов от исходных провайдеров мы создали интеграционную платформу с помощью пайплайнов SnapLogic. Благодаря этому заказчик получил дополнительные мощности и возможность настраивать процессы, не привлекая разработчиков. Новая платформа позволила штатно интегрировать в бизнес-процессы Salesforce, Adestra и Marketo.
Новая инфраструктура позволяет отделам, работающим с сайтами, сосредоточиться на самых важных функциях, таких как управление контентом, визуальное содержимое, A/B-тестирование и персонализация. В качестве основной CMS для управления всеми сайтами была выбрана платформа Sitecore. Она позволяет экспериментировать со структурой, повторно использовать контент для различных задач, получать персонализированные рекомендации и запускать A/B-кампании с целью получения сведений об интересах и предпочтениях посетителей сайта с минимальным вовлечением IT-персонала.
Рис. 2. Новый подход к архитектуре.
Результат
Улучшив процесс разработки и внедрив инструменты автоматизации, мы значительно ускорили срок вывода на рынок новых версий продукта. В данный момент на всех проектах работает непрерывная интеграция, а на многих также и непрерывное развертывание.
Благодаря разделению инфраструктуры заказчику удалось перейти на облачные сервисы, начать использовать современные платформы и уделить больше внимания разработке проектов, которые приносят прибыль.