Continuous Delivery with Jenkins declarative pipeline XPDays-2018-12-08

Editor's Notes

• #2: BДобрий день, ця доповідь про Jenkins Declarative Pipeline Open Source Tool для Continuous Delivery for µServices Хочемо поділитись своїм досвідом налаштування Continuous Delivery на проекті. DP наразі використовується успішно на декількох проектах
• #3: B Мене звати Зора Борис, Я працював System Architect ом на декількох проектах. У вільний час open соршу з Javatar community S Привіт я Сергій Петриченко, працюю Архітектором в Golden Dimension, Також співпрацюю з Javatar community S На данний момент наший головний приорітет в open сорсі реалізувати CI/CD best practices для µServices в Jenkins Declarative Pipeline Метою якого являється мінімізація часу на перехід на Continuous Delivery
• #4: S Вся наша робота знаходиться у відкритому доступі на github Якщо у Вас є пропозиції по функціоналу створюйте, будь-ласка, тікети Якщо хтось хоче зайти під час презентації на github, можете відсканить QRcode B sdfasdf
• #5: B Наша Agenda Ми почнемо з реальних ситуацій які були у нашому досвіді Потім перейдемо до теорії. Що рекомендують експерти? Покажемо демо Declarative Pipeline S Також подивимось приклади конфігурації Declarative Pipeline Переглянемо повний список, що на даний момент ми встигли реалізувати і може бути використаним на Ваших проектах Ще пройдемось по списку, що плануємо реалізувати найближчим часом Останньою зупинкою буде відповідь на Ваші запитання Якщо це не те що Ви очікували від почути, ще не пізно пошукати іншу доповідь
• #6: B Так виглядає робота devOps по мануальному деплою мікросервісів в прод На high load проекті Підніміть, будь-ласка, руки у кого на проекті деплой на прод автоматичний. (10 сек чекаємо) Дякую, десь % аудиторії
• #7: S Якщо Ваш devOps захворів, як виглядає Ваше делівері на прод? Знайома ситуація? Давайте перейдемо до реальний use case-ів
• #8: 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
• #9: 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
• #10: 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.
• #11: S Таким чином devOps стає ботелнеком У цій ситуації всі залишаються не задоволеними devOps - працює з рутиною і йому немає часу підняти голову на автоматизацію Developer - змінює контексти між тасками та не може вчасно віддати їх на тестування
• #12: 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
• #13: 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
• #14: 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
• #15: 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
• #16: B Так виглядало розподілення коштів в HP, До імплементації Continuous Delivery На іновації припадало лише 5% загальних витрат Їхня мета була, збільшити відсоток іновацій в 10 разів Свій шлях вони розписали в книжці Large-Scale Agile Development
• #17: 10 min S Для того щоб допомогти в Continuous Delivery for µServices Ми обрали найпопулярніший CI/CD tool - Jenkins Для того щоб розділити sensitive information від CI/CD best practice Вся реалізація пішла в pipeline shared library Вся sensitive інформація залишилсь в .yml файлі що підвантажується Jenkinsfile-ом І вона знаходиться в Вашому приватному репозиторії
• #18: B Багато best practices, що ми реалізували можна знайти в книжці Continuous Delivery written by Jez Humble & David Farley Також є непоганий ресурс від компанії thoughtworks, Де і працювали ці хлопці, коли писали цю книгу, Можете перейти по QR коду, якщо комусь цікаві ці ресурси Хто не встиг відсканувати, лінки ми відобразимо ще на останньому слайді
• #19: S Як запропонував Edwards Deming, Першочергово потрібно вдосконалити процес та вбудовувати якість в продукт
• #22: B Чому Continuous Delivery Зробити релізи безболісними та без ризиковими Пришвидшити випуск нових фіч Підвищити якість та стабільність продукту Зменшити витрати на розробку Підвищити задоволеність як клієнтів так і співробітників За допомогою швидкого фідбеку
• #23: SКлючові принципи Continuous Delivery Вбудовувати якість в продукт Працювати маленькими батчами Все що можна автоматизувати - автоматизуйте Невтомно вдосконалювати процес Кожен має бути відповідальним
• #25: B Deployment Pipeline Practices Білдіть один раз Деплойте однаково на всі енви Робіть smoke tests Тримайте енви схожими При збоях починайте пайплайн заново
• #27: S Low Risk Releases are Incremental Використовуйте фіча флаги, ви зможете швидко відкатиться лише змінивши конфігурацію Blue-green deployments Canary releases Dark Launching - це коли Ви викатили бекенд фічу, яку не бачить ui, потім окремим релізом оновлюєте ui і фіча вже доступна, якщо щось йде не так, можна відкотить ui Production Immune System (про неї на окремому слайді)
• #29: B Інфраструктура має бути стабільною Якщо Ваш сервер викинуть у вікно, Скільки часу Вам знадобиться щоб відновити його? Це запитання ставить Мартін Фаулер у статті Phoenix Server свого блогу
• #30: We also have all things in vcs We have not implement monitoring yet Automatic self corrects to desired state done by mesos & kubernetes
• #31: S/B TODO 1 minutes
• #32: S Так виглядає реакція devOps на prod issue після того як всі практики були реалізовані. Бізнес prod issue може взагалі не помітити B ! [емоційно] Це відчуття стабільності After all practices implemented on your CI/CD pipeline You are not afraid anymore
• #39: What about security?
• #46: 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
• #47: Let’s make adoption easier
• #49: На випадок якщо Вам не сподобалась презентація, Ми вставили ось цього котика, це трішки згладити ситуацію Please ask questions at speaker zone