DOU Labs: як в EPAM створили Delivery Platform – акселератор для старту проектів - SEO Blog - все про пошукову оптимізацію та веб розробку українською.

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

У рубриці DOU Labs ми запрошуємо IT-компанії ділитися досвідом власних цікавих розробок і внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на [email protected] .

Привіт. Мене звуть Євген Моспан, працюю 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 with OpenShift ;
Continuous Integration and Continuous Delivery with Fabric8 ;
OpenShift.io ;
І, наприклад, дуже свіже рішення на основі Kubernetes і Istio .

При найближчому розгляді адаптації цих рішень виникає цілий ряд труднощів. Так, 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, з можливістю замінювати інструменти аналогами.
Централізована система автентифікації та авторизації. Організація ЄДИНОГО для всіх 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 або СКВ.	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. Після успішного розгортання здійснюється запуск автоматизованих тестів, налаштованих для цього етапу і контроль 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). Це дозволяє молодим фахівцям відразу звикати до найвищим стандартам розробки коду на сучасних проектах.

Дякую вам за увагу і прочитання даної статті. На питання, що виникли в міру сил постараюся відповісти в коментарях :)

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

SEO Блог