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:

Схематично рішення можна представити у вигляді наступного набору шарів. Установка на будь-яку інфраструктуру, де є можливість використовувати 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 виглядає дуже багатообіцяючою платформою, в якій, проте, є кілька важливих «але»:

OpenShift.io заслуговує більш детального вивчення і окремої статті. Як, втім і нова висхідна зірка — KNative. Говорити багато про цієї технології поки рано, подивимося, наскільки далеко вони зможуть зайти. Початок виглядає багатообіцяючим.

З чого складається і як працює EPAM Delivery Platform

Для подальшого розповіді про архітектуру та користь EDP для нових проектів в EPAM, варто відразу описати її основні функції:

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

Список інструментів для організації 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 або СКВ. 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:

Опубліковано: 04/10/18 @ 07:00
Розділ Різне

Рекомендуємо:

Финстрип за Вересень 2018. 83К
DOU Books: 5 книжок для тих, хто не боїться жити, від Василя Ульянова, співзасновник Genesis
DOU Проектор: Software Riot — гра-платформер про програміста, що рятує офіс від комп'ютерного вірусу
Більше 1К лідов за перший місяць для сайту з навчання в Польщі
Що не так із апельсиновим соком