When you start your journey with µServices, you should be confident with your delivery lifecycle. In case of mistake, you should be able to navigate to appropriate tag in vcs to reproduce the bug with a test & go though pipeline within 3 hours to production with high confidence of quality.
We will discuss set of tools that could help you to achieve this within 3 months on your project. It does not include system decoupling suggestions. And in the same time, if you decide to break down monolith, it is better to do with dev & devOps best practices.
4. ● Real life use cases, where CI/CD could help
● Theory and best practices from CI/CD experts
● Demo with implementation of some best practices
● Declarative pipeline examples
● Features that already implemented
● Features that we plan to do
● Q&A
Agenda
16. Jenkins Declarative Pipeline (DP)
Declarative pipeline is open source
Jenkins Global Shared Library,
free of charge for commercial use
17. DP is implementation of best practices
https://martinfowler.com/books/continuousDelivery.html
https://www.thoughtworks.com/continuous-delivery
18. Build Quality In
“Cease dependence on mass
inspection to achieve quality.
Improve the process and
build quality into the product
in the first place.”
W. Edwards Deming
19. Why Continuous Delivery?
● Make releases painless, low risk events
● Reduce time to market
● Increase software quality and stability
● Reduce cost of ongoing software development
● Increase customer and employee satisfaction
○ Creates fast feedback loops
20. Key Principles of Continuous Delivery
● Build quality in
● Work in small batches
● Computers do repetitive task, people solve problems
● Relentlessly pursue continuous improvement
● Everyone is responsible
21. Deployment Pipeline Practices
● Only build your packages once
● Deploy the same way to every environment
● Smoke test your deployments
● Keep your environments similar
● If anything fails, stop the line!
22.
23. Low Risk Releases are Incremental
● Feature toggles
● Blue-green deployments
● Canary releases
● Dark Launching
● Production Immune System
24. If someone threw a server out
of the window, how long would
it take to recreate it?
Infrastructure stability
https://martinfowler.com/bliki/PhoenixServer.html
34. Features that already implemented
● Release suits: service, ui, library, service-with-db
● Build types: maven, npm, python, php, sencha
● Integration of your system/ui tests
● Integration with Sonar
● works with gitlab, github, bitbucket (git & mercurial)
● works with Mesos & Marathon
35. Features that we plan to do
● Blue-green deployments
● Secure deployment to production
● Production Immune System check adoption
● Performance tests easy integration
● Adopt service orchestration with Kubernetes
● Canary releases
39. Takeaways
● Let’s standardize free of chage CI/CD implementation
● Share with us your feedback what is missing
● Use Declarative Pipeline on your project or sub project
● Contribute with Javatar to Declarative Pipeline
● Experiment with Continuous improvements
BДобрий день, ця доповідь про Jenkins Declarative Pipeline
Open Source Tool для Continuous Delivery for µServices
Хочемо поділитись своїм досвідом налаштування Continuous Delivery на проекті.
DP наразі використовується успішно на декількох проектах
B
Мене звати Зора Борис,
Я працював System Architect ом на декількох проектах. У вільний час open соршу з Javatar community
S
Привіт я Сергій Петриченко, працюю Архітектором в Golden Dimension,
Також співпрацюю з Javatar community
S
На данний момент наший головний приорітет в open сорсі
реалізувати CI/CD best practices для µServices в Jenkins Declarative Pipeline
Метою якого являється мінімізація часу на перехід на Continuous Delivery
S
Вся наша робота знаходиться у відкритому доступі на github
Якщо у Вас є пропозиції по функціоналу створюйте, будь-ласка, тікети
Якщо хтось хоче зайти під час презентації на github, можете відсканить QRcode
B
sdfasdf
B
Наша Agenda
Ми почнемо з реальних ситуацій які були у нашому досвіді
Потім перейдемо до теорії. Що рекомендують експерти?
Покажемо демо Declarative Pipeline
S
Також подивимось приклади конфігурації Declarative Pipeline
Переглянемо повний список, що на даний момент ми встигли реалізувати
і може бути використаним на Ваших проектах
Ще пройдемось по списку, що плануємо реалізувати найближчим часом
Останньою зупинкою буде відповідь на Ваші запитання
Якщо це не те що Ви очікували від почути, ще не пізно пошукати іншу доповідь
B
Так виглядає робота devOps
по мануальному деплою мікросервісів в прод
На high load проекті
Підніміть, будь-ласка, руки у кого
на проекті деплой на прод автоматичний. (10 сек чекаємо)
Дякую, десь % аудиторії
S
Якщо Ваш devOps захворів,
як виглядає Ваше делівері на прод?
Знайома ситуація?
Давайте перейдемо до реальний use case-ів
B
Так Давайте перейдемо до реальних use case-ів
Database backward compatibility
У Вас новий реліз сервіса з великою реляційною базою даних
QA все відтестили і Ви собі сидите на грумінгу ні про що не хвилюєтесь,
А що може піти не так?
Але прибігає збентежений девопс менеджер
і терміново просить підійти до хлопців які деплоять на прод
(Prod deploy failed according to Out of memory issue
Rollback is not possible because db has not backward compatible change
Restore from dump is time consuming, huge penalty would apply
)
issue:
you deploy service in production and it fails to start with out of memory error you try to switch to previous version, but service does not start because flyway make some changes and previous version could not start with new database schema. Your customer has downtime. Your devOps add to µService 200 Gb of RAM and this does not help, somebody from devs read all rows from the table into memory (on dev env this works because table has less rows)
Workaround:
devOps deleted all cron jobs (after some other guess tries) and this help to investigate offline, and resolve issue
Best practice:
verify database compatibility with previous 3 versions, esspecially on monolith with huge volumes
BВам кажуть, що сервіс не піднявся і падає з out of memory, навіть якщо йому дати 200 Gb RAM,
Ви не довго думаючи пропонуєте ролбек, у нас же все протещено!
Ролбек уже пробували, сервіс не піднімається,
В логах пише, що немає колонки з потрібним типом.
В цей момент Ви розумієте повну картину:
при релізі нової версії, на базу даних накатились скрипти flyway,
які містили не backward compatible зміни,
а саме “Change column type”
Коли відбувається ролбек, то версія бази даних залишається новою
Проти якої працює стай код, який очікував інший тип колонки
На проекті є Database change strategy, але це автоматично не тестувалось
Правильним рішенням було б додати нову колонку і тимчасово писати в обидві, а читати з нової
а потім через 3 релізи видалить стару колонку
Цього зроблено не було
Залишається варіант підйому бази даних з дампу,
Що потребує більшого даунтайму сервіса
А у Вас скажімо підписаний SLA із замовником, якщо даунтайм перевищує 20 хв на місяць штраф $65k
(цифри навмисно змінені, щоб не порушить NDA)
(Prod deploy failed according to Out of memory issue
Rollback is not possible because db has not backward compatible change
Restore from dump is time consuming, huge penalty would apply
)
issue:
you deploy service in production and it fails to start with out of memory error you try to switch to previous version, but service does not start because flyway make some changes and previous version could not start with new database schema. Your customer has downtime. Your devOps add to µService 200 Gb of RAM and this does not help, somebody from devs read all rows from the table into memory (on dev env this works because table has less rows)
Workaround:
devOps deleted all cron jobs (after some other guess tries) and this help to investigate offline, and resolve issue
Best practice:
verify database compatibility with previous 3 versions, esspecially on monolith with huge volumes
S
Коли у Вас на проекті не вистачає devOps ресурсів,
починається надлишкова синхронізація та змагання між командами
За часту у Ваша таска не завжди найприорітетніша,
тому Вам приходиться відкаласти її та переключитись на іншу задачу,
що змушує Вас тримати 2 контекста
Пул не закритих задач Вашої команди збільшується
Навіть якщо задача може бути виконана Вами за 10 хв,
але на проекті чітко відмежовані відповідальності, у Вас просто не має прав на це
Team has meeting about if devOps has free time to deploy µService on env and into prod
5 members discuss what they will do if devOps has no time because he fixes/tune kafka for prod
CTO says that money only of devs (features) not for devOps
control dev & qa env:
issue:
you have task to create some feature flow, for this purposes you need to create 2 additional µServices, each have it''s own database. You have one devOps in the project, who in on vacation now. Nobody except him has rights to env setup
workaround:
you ask devOps on his vacation that you have some job for him, and you 3-rd in the line, because all other are also depend on him
best practice:
dev & qa env should be controlled by dev, qa & devOps. To create new service you should not spend a lot of time, it should be 2 minutes job.
S
Таким чином devOps стає ботелнеком
У цій ситуації всі залишаються не задоволеними
devOps - працює з рутиною і йому немає часу підняти голову на автоматизацію
Developer - змінює контексти між тасками та не може вчасно віддати їх на тестування
B
Іноді проблема не тривіальна
і з логів мало що зрозуміло
Проте на мікросервісній архітектурі,
де в одному бізнес флоу може бути задіяно десяток мікросервісів
важко задебажить
Підняти локально - тяжко і часо-затратно або навіть не підйомно по ресурсам
bug reproduce or debug µService env:
issue:
you have 6 µServices and 1 monolith in one feature flow, each service has own database and some of them connected to message broker, all of them connected to service registry, cloud configuration & all request goes though api-gateway (zuul)
workaround:
you write docker compose and hope you have enough cpu & ram to handle
best practice:
you can pass cloud config url and your service though vpn will be as a part of µService network, all services can see you and send request, and your service can see them all as well
SУ вас баг в проді з первним µService, stack-trace вказує на строки коду,
Але вони не відповідають поточній версії, а таг ніхто не зробив
Цей сервіс вже 2 роки в проді, але його версія 1.0-SNAPSHOT
І в репозиторію лише один бранч - master
Щоб знайти відповідну ревізію Ви уточнююєте дату викатки в прод у devOps
і шукаєте коміт до цієї дати
Лише після цього ви знаходите вірну строку в якій відбулась помилка
revision tag:
issue:
you have issue in some µService, stack-trace points to some line in the code and you can not find it because release tag was not created and this service 3 years in production with version 1.0-SNAPSHOT with only one branch - master
workaround:
with devOps we find when it was deployed and try to find appropriate commit to checkout that version
best practice:
µService that now is in production has /info url with release version that corresponds to release tag in VCS
B
У Вас є публічний API, який Ви також використовуєте самі internally
Коли відбуваються зміни в цей API
зазвичай Ви підправляєте внутнішній сервіс, що його використовує
А про екстернал систему в основному памятали колишні співробітники,
Але тестів на неї не написали.
Нові QA тестують лише внутрішню взаємодію та апрувлять реліз.
Після нього devOps в проді відловлюють помилки від екстернал клієнтів
Service changed with one of downstream services
But all other external clients failed, because api not supported old requests
System/contract tests in pipeline
S
За часту devOps не привязується до якоїсь мови програмування.
На попередньому проекті він міг займаться PHP or Python
Для яких компіляція не потрібна та є свої нюанси по деплою на прод.
В поточному проекті йому потрібно налаштувать деплоймент процес
Для java, groovy or scala, для яких він має розшукати best practices.
Це може бути тривалим процесом і не факт, що всі практики будуть задіяні
devOps previously deployed only php or python code (no need to compile)
Change paradigma when he switched to java/groovy/scala
He does not know best practices how to do it and need spend more time to achieve results
B
Так виглядало розподілення коштів в HP,
До імплементації Continuous Delivery
На іновації припадало лише 5% загальних витрат
Їхня мета була, збільшити відсоток іновацій в 10 разів
Свій шлях вони розписали в книжці Large-Scale Agile Development
10 min
S
Для того щоб допомогти в Continuous Delivery for µServices
Ми обрали найпопулярніший CI/CD tool - Jenkins
Для того щоб розділити sensitive information від CI/CD best practice
Вся реалізація пішла в pipeline shared library
Вся sensitive інформація залишилсь в .yml файлі що підвантажується Jenkinsfile-ом
І вона знаходиться в Вашому приватному репозиторії
B
Багато best practices, що ми реалізували можна знайти в книжці
Continuous Delivery written by Jez Humble & David Farley
Також є непоганий ресурс від компанії thoughtworks,
Де і працювали ці хлопці, коли писали цю книгу,
Можете перейти по QR коду, якщо комусь цікаві ці ресурси
Хто не встиг відсканувати, лінки ми відобразимо ще на останньому слайді
S
Як запропонував Edwards Deming,
Першочергово потрібно вдосконалити процес
та вбудовувати якість в продукт
B
Чому Continuous Delivery
Зробити релізи безболісними та без ризиковими
Пришвидшити випуск нових фіч
Підвищити якість та стабільність продукту
Зменшити витрати на розробку
Підвищити задоволеність як клієнтів так і співробітників
За допомогою швидкого фідбеку
SКлючові принципи Continuous Delivery
Вбудовувати якість в продукт
Працювати маленькими батчами
Все що можна автоматизувати - автоматизуйте
Невтомно вдосконалювати процес
Кожен має бути відповідальним
B
Deployment Pipeline Practices
Білдіть один раз
Деплойте однаково на всі енви
Робіть smoke tests
Тримайте енви схожими
При збоях починайте пайплайн заново
S
Low Risk Releases are Incremental
Використовуйте фіча флаги, ви зможете швидко відкатиться лише змінивши конфігурацію
Blue-green deployments
Canary releases
Dark Launching - це коли Ви викатили бекенд фічу, яку не бачить ui, потім окремим релізом оновлюєте ui і фіча вже доступна, якщо щось йде не так, можна відкотить ui
Production Immune System (про неї на окремому слайді)
B
Інфраструктура має бути стабільною
Якщо Ваш сервер викинуть у вікно,
Скільки часу Вам знадобиться щоб відновити його?
Це запитання ставить Мартін Фаулер
у статті Phoenix Server свого блогу
We also have all things in vcs
We have not implement monitoring yet
Automatic self corrects to desired state done by mesos & kubernetes
S/B
TODO
1 minutes
S
Так виглядає реакція devOps на prod issue
після того як всі практики були реалізовані.
Бізнес prod issue може взагалі не помітити
B
! [емоційно] Це відчуття стабільності
After all practices implemented on your CI/CD pipeline
You are not afraid anymore
What about security?
It is hard to make fluent CI/CD in entire organization in one shot
Probably it would be better to start with Innovators & Early adopters
And make POC with them
Let’s make adoption easier
На випадок якщо Вам не сподобалась презентація,
Ми вставили ось цього котика, це трішки згладити ситуацію
Please ask questions at speaker zone