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

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на  Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. .

Привет. Меня зовут Евгений Моспан, работаю 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). Это позволяет молодым специалистам сразу привыкать к самым высоким стандартам разработки кода на современных проектах.

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

Похожие статьи:
Управління дизайн-командою передбачає багато спілкування з клієнтами, дизайнерами, бізнес-аналітиками, розробниками тощо. І в цьому...
[В рубрике «Как я работаю» мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах...
[Об авторе: Дима Малеев — Solution Architect, работает в ИТ более 10 лет. С 2014 года — директор Lviv Code School] Всем привет, решил...
StartIT training center стал организатором сертификационного класса Professional Scrum Master от Scrum.org! Professional Scrum Master (PSM) — это курс,...
[DOU Hobby — рубрика о нетехнических проектах IT-специалистов: творчество, интересное хобби и другие...
Яндекс.Метрика