QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

DOU Labs: как в EPAM создали Delivery Platform — акселератор для старта проектов

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.

Привет. Меня зовут Евгений Моспан, работаю Solution Architect в компании EPAM. Сегодня я хочу рассказать о проекте под названием EPAM Delivery Platform, целью которого — минимизировать время для построения на проекте эффективных CI/CD практик.

Идея проекта

Наверняка каждый из вас наблюдал такую картину. Начинается новый проект, у всех амбициозные планы сделать мир лучше, использовать проверенные практики с предыдущих проектов, построить CI/CD своей мечты. В общем, за все хорошее, против всего плохого. Уверен, что есть проекты, на которых получается воплотить эти мечты в реальность, но есть и такие, на которых это не удается в силу разных причин. Например, команда не может договориться, потому что у всех разное представление о хорошем, у заказчика специфичная инфраструктура и т. д. и т. п. В итоге имеем шансы примерно 50/50: либо получится, либо нет. Рано или поздно, в рамках какой-либо инициативы возникает стремление склонить чаши весов в сторону более успешных запусков проектов.

В EPAM одной из таких инициатив стал наш проект под названием EPAM Delivery Platform (далее по тексту сокращенно EDP). Сама идея возникла в конце 2017 года. Основная задача EDP — обеспечить минимальное время для так называемого спринта 0, когда и происходит формирование основных практик на проекте, конфигурирование CI/CD и другие процессы. После этого приступить в спринте 1 к разработке бизнес-фич, которые можно демонстрировать заказчику, автоматизировано тестировать и пропускать через конфигурируемые Quality Gates на различных этапах CI/CD процесса.

Цель EDP: сделать длительность спринта 0 — максимум в 2 недели, которые включают в себя разворачивание инфраструктуры, настройку CI/CD под конкретный проект, обучение команды тем инструментам и pipelines, которые используются в решении.

Команда: в ней собраны архитекторы и инженеры (software engineers, DevOps, testing engineers), которые имеют достаточно глубокую экспертизу и опыт разработки проектов на Java, JavaScript, .NET с использованием современных CI/CD практик.

Девиз: «Business value from Sprint 1».

Основные технологии, выбранные для проекта

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

Основные технологии EDP:

  • Контейнеризация на основе Docker.
  • Оркестрирование контейнеров посредством Kubernetes.
  • Platform as a Service поверх Kubernetes — OpenShift.

Схематично решение можно представить в виде следующего набора слоев. Установка на любую инфраструктуру, где есть возможность использовать 3 технологии, описанные выше.

Опытные пользователи OpenShift или Kubernetes заметят, что существует немало уже готовых решений или референсных статей, таких как:

При ближайшем рассмотрении адаптации этих решений возникает целый ряд сложностей. Так, CI/CD от OpenShift описывает лишь базовые принципы, как CI/CD может быть организовано на базе платформы и не детализирует реализацию и специфику использования.

Команда Fabric8, с другой стороны, проделала огромный, я бы даже сказал титанический объем работы по адаптации Java-приложений на базе Spring Cloud + Netflix, обещая возможность деплоймента микросервисных решений как в OpenShift, так и в Kubernetes. К слову, именно этот продукт оказал наибольшее влияние на архитектуру и возможности EDP.

В тоже время с точки зрения конечного пользователя Fabric8 не выглядит легким в применении. Анализируя возможности Fabric8, команда EDP даже шутила, что это the most bleeding cutting edge they’ve ever seen. Причиной этому была банальная невозможность проинсталлировать стабильную версию платформы, будь то на minikube/minishift или полноценные кластеры OpenShift и Kubernetes. Возможно, это связано с тем, что судя по саммитам Red Hat (например, это видео) команда разработчиков Fabric8 помогает строить OpenShift.io, что повлекло за собой снижение темпов разработки самого Fabric8.

OpenShift.io выглядит очень многообещающей платформой, в которой, однако, есть пару важных «но»:

  • Интегрированная система управления проектом значительно уступает привычным Jira, Rally, Trello и т. д. Многие ли захотят использовать новый инструмент с отсутствием уже привычного функционала?
  • Разработка в браузере на основе Eclipse Che выглядит очень привлекательно с точки зрения менеджера и Ops, но мне сложно представить там радостно работающих senior developers, привыкших к взрослым полнофункциональным IDE.

OpenShift.io заслуживает более детального изучения и отдельной статьи. Как, впрочем и новая восходящая звезда — KNative. Говорить много об этой технологии пока рано, посмотрим, насколько далеко они смогут зайти. Начало выглядит многообещающим.

Из чего состоит и как работает EPAM Delivery Platform

Для дальнейшего рассказа об архитектуре и пользе EDP для стартующих проектов в EPAM, стоит сразу описать ее основные функции:

  • Интегрированный набор инструментов для организации CI/CD, с возможностью заменять инструменты аналогами.
  • Централизованная система аутентификации и авторизации. Организация SSO для всех CI/CD инструментов и интеграция с корпоративным SSO. RBAC-контроль доступа к ресурсам платформы.
  • Прозрачная интеграция source code приложений в CI/CD инструменты.
  • Конфигурируемый continuous delivery pipeline с возможностью настройки последовательности его этапов (stages).
  • Обеспечение автоматизированного тестирования (functional, security, performance etc) каждого из этапов CD pipeline, а также конфигурация и контроль quality gates для каждого из них.
  • Мониторинг кластера для разработки и централизованный сбор логов.

Архитектура EDP представляет из себя набор взаимосвязанных абстрактных компонентов и API для них. С их помощью имплементируются основные функции платформы. Компоненты можно разбить на 3 крупных логических блока:

  • Инструменты для организации CI/CD.
  • Компоненты для запуска автоматизированных тестов.
  • Continuous delivery pipeline, состоящая из произвольного набора stage. В их рамках производится запуск автоматизированных тестов и контроль прохождения посредством анализа quality gates.

Список инструментов для организации CI/CD, их назначение и поддерживаемые имплементации представлены в таблице ниже:

КомпонентНазначениеИмплементации
VCSСистема контроля и управления версиями. Она обеспечивает надёжное хранение в отдельных репозиториях кода приложений, которые добавляются в платформу.GitLab, Bitbucket
IdentityServiceСервис, который хранит данные пользователей EDP, а также роли и привилегии, которыми они обладают в каждом из инструментов. Является сервисом аутентификации пользователей, позволяя делегировать аутентификацию другим IdentityService.KeyCloak
AutorizationServerСервер, который управляет правами пользователей, обеспечивая центральный и первичный источник информации IdentityService. В IdentityService полученные права или роли преобразуются в те, которые используются в компонентах EDP.LDAP
CorporateSSOБлагодаря этому серверу пользователи могут единоразово ввести пароль и получить доступ ко всем зарегистрированным ресурсам в соответствии со своими привилегиями.ADFS
CodeReviewОсновной компонент для валидации исходного кода. Все изменения участниками команды в репозиториях своих приложений проходят через Code Review процесс. Помимо ручного шага (выполненного лидером команды, например), включает в себя также автоматизированные шаги (проверка компилируемости, запуск unit тестов и т.д.)

EDP определяет набор привилегий для CodeReview, посредством которых можно разграничить возможности членов команды по управлению изменениями в исходном коде. Например:

  • Approved code changes.
  • Submit code changes.
  • Block code changes.
Gerrit
CICDServerЦентральный компонент для исполнения различного рода задач, связанных с жизненным циклом разработки.Jenkins
СodeAnalyzerАнализатор статического кода. Позволяет контролировать его качество с точки зрения различных quality attributes (maintainability, security и т. д). Это происходит на основании сконфигурированных правил и порогов (quality gates). Такой инструмент также позволяет анализировать исторические данные и понимать тренд по изменению качества кода.SonarQube
ArtifactsStorageХранилище всех «бинарных» артефактов (jar, zip и т. д.) которые создаются CI сервером во время запуска pipelines на основании событий из CodeReview или VCS.Nexus
DockerStorageХранилище для docker images, которые создаются CI-сервером.Docker Registry
BinaryPackagerИнструменты для создания «бинарных» артефактов из исходного кода.Maven, NPM
DockerPacagerИнструменты для создания docker images на основании «бинарных» артефактов.OpenShift Source to Image
CockpitИнструмент EDP, позволяющий добавлять приложения и автоматизированные тесты для них из существующих репозиториев и интегрировать их в инструменты перечисленные выше.EDP custom tool
CentralizedLoggingХранилище для логов из всех запускаемых приложений в OpenShift, включая инструменты самого EDP.EFK
MonitoringИнструмент для мониторинга cluster nodes и dockers, запускаемых в кластере. Prometheus

Диаграмма ниже представляет собой логический дизайн EDP на базе описанного выше набора инструментов:

Как видно из таблицы и диаграммы выше, EDP опирается на известные и широко применяемые opensource инструменты, посредством которых обычно строят CI/CD на большинстве проектов. Основной added value EDP — это стандартизация API по интеграции и взаимодействие этих инструментов как во время инсталляции платформы, так и при ее использовании. Основная цель — предоставление точек расширения для пользователей EDP и возможности замены компонентов, которые входят в платформу. Рассмотрим более конкретные примеры. Как уже было сказано выше, EDP выделяет два основных вида API:

  • Integration. Каждый инструмент необходимо установить в платформу, сконфигурировать, интегрировать в SSO. Поэтому базовые функции такие:
    • install()
    • configure()
    • integrateWithSSO()
    Более специфичным является интеграция инструментов между собой для обеспечения заявленных функций EDP. Например, для СodeAnalyzer можно выделить такие:
    • uploadEdpQualityProfiles()
    • registerCIServerFunctionalUser()
  • Runtime. После установки платформы пользователи могут добавлять свои приложения и конфигурировать для них CD pipeline. Эти возможности составляют вторую часть API, которую EDP предоставляет для описанных инструментов. Из наиболее понятных примеров можно привести следующие:
    • CodeReview:
      • registerNewApplication(), который позволяет зарегистрировать новое приложение и осуществлять процесс code review.
    • CICDServer:
      • registerFeatureBranchPipeline(), который обеспечивает добавление CI pipeline для запуска на каждый commit в feature branch.
      • registerPullRequestPipeline() регистрирует pipeline для каждого добавленного приложения, который отвечает за его сборку после подтверждения pull request.
      • addStageToPipeline() позволяет добавить новый stage в CD pipeline, обеспечивая механизм автоматического промоушена между stage.

    Схематично компоненты EDP и их API можно представить в виде следующей high-level диаграммы:

    Выше была затронута тема CI/CD pipeline, рекомендуемую EDP, которую можно представить следующим образом:

    Как видим, EDP выделяет два основных этапа для CI:

    • интеграция и проверка кода, который создаётся в feature branch;
    • интеграция, проверка и сборка кода после сабмита pull request.

    EDP поддерживает возможность не только интеграции кода на двух описанных выше этапах, но и их установки на временные environments. Последние доступны либо конкретному разработчику, либо команде. Стоит отметить, что такой подход к разработке может оказаться достаточно ресурсоемким с точки зрения инфраструктуры. Поэтому рекомендацией по умолчанию от EDP является использование ограниченного количества environment, куда производится deploy последних версий приложений и осуществляется контроль их качества. С одной стороны, это экономит ресурсы инфраструктуры с другой стороны — уменьшает так называемый «integration hell». По умолчанию EDP рекомендует следующий набор shared environment для основной ветки разработки:

    Где

    • SIT — System Integration testing — этап, на котором рекомендуется запуск автоматизированных тестов.
    • QA — Quality Assurance — этап, на котором осуществляется верификация новой функциональности разрабатываемых приложений.
    • UAT — User Acceptance testing — этап для демонстрации приложения конечным пользователям и предоставление им возможности самостоятельно поработать с новой функциональностью.

    Для каждого из этапов осуществляется deployment всех приложений на выделенный environment. После успешного deployment осуществляется запуск автоматизированных тестов, настроенных для этого этапа и контроль quality gates. Схематично pipeline можно представить в виде следующих высокоуровневых шагов:

    Отдельного внимания заслуживает EDP Cockpit, который представляет из себя web-интерфейс для Runtime API EDP. Cockpit позволяет осуществлять добавление новых приложений, конфигурировать последовательность этапов для CD pipeline, определять, какие автоматизированные тесты запускать на том или ином этапе и т. д. Работа с Cockpit начинается с прохождения wizard, который позволяет настроить EDP под конкретные нужды:

    Далее можно добавить приложения, платформенные сервисы и проекты с автотестами:

    Завершается работа wizard конфигурированием CI/CD Pipeline:

    Давайте подытожим, что же получает пользователь EDP после установки в OpenShift кластер:

    • Интегрированный набор CI/CD инструментов с настроенным SSO, централизованной аутентификацией и авторизацией. Это облегчает доступ конечных пользователей к ресурсам платформы и позволяет гибко контролировать уровень этого доступа.
    • Исходный код EDP с возможностью его кастомизации под нужды проектов.
    • Быстро добавлять исходный код приложений и проекты с автоматизированными теста посредством Cockpit.
    • Настраивать CD pipeline, управлять набором автоматизированных тестов, запускаемых на каждом этапе, а также назначать quality gates для обеспечения контроля качества.
    • Инструменты для централизованного сбора логов и мониторинга.

    Более того, несколько экземпляров EDP могут быть проинсталлированы в один OpenShift кластер, что позволяет разрабатывать несколько проектов на одной инфраструктуре.

    Что сейчас и что дальше

    EDP сейчас уже не просто внутренняя инициатива EPAM. Теперь это платформа, на которой имплементировано несколько проектов и начинаются новые. Один из них предполагает размер команды до 100 человек с различной экспертизой, что повышает уровень сложности и ответственности настройки платформы. AWS и Azure являются Cloud Provider для этих проектов, а потому команды EDP получают важный опыт по управлению кластерами OpenShift в public cloud в соответствии с последними рекомендациями Red Hat.

    Естественно, команда EDP не планирует останавливаться на достигнутом. Наши следующие шаги:

    • Добавление новых инструментов, которые реализуют API компонентов EDP.
    • Более тонкая настройка pipeline на этапе их добавления.
    • Расширение списка поддерживаемых технологий для разработки и framework.
    • Более тесная интеграция c managed services of public clouds.
    • Развитие инфраструктуры и конфигурации кластера OpenShift для соответствия самым строгим security стандартам.
    • Интеграция серверов для хранения и анализа результатов performance и security тестирования и многое другое.

    Важным моментом развития EDP является внедрение этой платформы для проектов, которые разрабатываются в рамках EPAM RD (Resource Development). Это позволяет молодым специалистам сразу привыкать к самым высоким стандартам разработки кода на современных проектах.

    Спасибо вам за внимание и прочтение данной статьи. На возникшие вопросы по мере сил постараюсь ответить в комментариях :)

LinkedIn

4 комментария

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

Дайте угадаю, те что имплементированы = проекты авторов платформы. А никто из вне это не использует.

Если просуммировать имплентированные (2) и имплементируемые (3) проекты, то вы угадали на 20 %, так как только в одном проекте один из авторов принимает непосредственное участие. Платформа пользуется большим интересом внутри компании и одной из задач core команды является сделать ее понятной для широкого круга людей.

Что такое «имплементируемые» проекты в данном случае? Эти новые проекты пользуются полностью этой платформой полностью для билдсервера, мониторинга, логинга, SSO, etc? Сколько там человек?

Мне с трудом верится, что такая opinionated платформа может быть востребована.

Имплементируемые = «in progress». Сейчас это новые проекты. Акселератор позволяет команде, начинающий проект, не тратить много времени на конфигурирование основных инструментов. В процессе развития сами решают как эволюционировать платформу, какие модули нужно заменить, какие добавить, какие наоборот отключить.
Перечисленные вами аспекты помогают организовать более стабильную, прозрачную работу.
На сегодняшний день они так или иначе являются стандартом, каждый раз все конфигурировать с нуля просто не имеет смысла.
Количество человек разное: от 15 до 50 (на данный момент).

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

Подписаться на комментарии