Download to read offline
Uploaded byBinary Studio
Introduction to DevOps. Continuous Integration by Myroslav Dmytrus
Continuous integration is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Every change is built and tested on an integration machine. The goal is to detect problems early to minimize integration issues. Continuous integration uses automated builds that are triggered on every code commit to provide rapid feedback. It helps teams integrate code and build quality in from the start.
Introduction to DevOps. Continuous Integration by Myroslav Dmytrus
- 1. Introduction to DevOps.Continuous Integration Myroslav Dmytrus .Net developer at Binary Studio
- 2. Terms Continuous integration Continuous delivery / continuousdeployment DevOps
- 3. What is Continuousintegration? ● A development methodology ● Of daily developer integrations ● Verified by automated builds ● Every commit triggers a build − As soon as you have completed an independent functionality − A full build on another, empty machine
- 4. Review User 1 User 2 Commit Commit RepositoryCI Server Integration Build Machine Feedback Mechanism
- 5. Why use continuousintegration ● Automate the build ● Make the build self testing ● Keep the build fast ● Fix Broken Builds Immediately ● Every Commit Should Build the Mainline on an Integration Machine
- 6. ● Maintain aSingle Repository ● Everyone Commits To the Mainline Every Day ● Test in a clone of the production environment ● Make it Easy for Anyone to Get the Latest Executable ● Everyone can see what's happening ● Automate deployment
- 7. Self-testing build ● Directlygo from source to running build − No manual copying − No click on dialog boxes − No configuration file editing ● Test with − Unit tests − Functional tests (web tests) − Performance tests ● Responsible persons should be notified when anything fails
- 9.
- 10.
- 15. Continuous Delivery ● Continuousdelivery/Continuous deployment ● Continuous, successful and repeatable methodology to deploying code ● Automated the steps of taking checked in code and making it run on production servers, used by customers
- 16.
- 17. 8 Principles ofContinuous Delivery ● The process for releasing/deploying software MUST be repeatable and reliable ● Automate everything ● If somethings difficult or painful, do it more often ● Keep everything in source control ● Done means “released” ● Build quality in ● Everybody has responsibility for the release process ● Improve continuously
- 18. Continuous Delivery Vs.Continuous Deployment
- 19.
- 21. Virtual machines docker Server Hypervisor HostOS kernel bins/libs app kernel bins/libs app Server Host OS bins/libs app bins/libs app VM container
- 22.
- 23.
- 24.
- 25. DevOps: the threestage conversation
- 26. List of DevOpsPractices ● Infrastructure as Code (IaC) ● Continuous Integration ● Automated Testing ● Continuous Deployment ● Release Management ● App Performance Monitoring ● Load Testing & Auto-Scale ● Automated Environment Deprovisioning ● Automated Recovery
Editor's Notes
- #3 Головні терміни, щоб було зрозуміло про що ми будемо говорити кожний термін розширяє попередній
- #4 Continuous Integration це практика розробки програмного забезпечення, де члени команди інтегрують свою роботу часто, як правило, кожна людина інтегрує принаймні щодня - що призводить до виникнення кількох інтеграцій в день. Кожна інтеграція перевіряється за допомогою автоматизованої збірки (включаючи тести) для виявлення помилок інтеграції якомога швидше. Багато команд вважають, що цей підхід допомагаю значно скоротити проблеми інтеграції та дозволяє команді розробки програмного забезпечення розвивати продукт швидкими темпами.
- #5 на зображенні це буде виглядати приблизно так. Є багато етапів де можуть виникнути проблеми в білді. Хтось закомітив зміни скоріше за тебе і змінив логіку яку ти використовував, білд може зламатись. Ти мерджиш виправляєш зміни, якщо код пересікався. Пушиш все на репозиторій. Де CI білдить проект. Якщо все гаразд, приходить нотіфікації що все успішно, якщо є проблеми потрібно здійснити повторну перевірку коду і знову все закомітити. Потім в чергу вступають тести, тести перевіряють чи вся логіка працює як планувались і чи нічого не зламалось в ході наших змін. (???? щоб не було ситуації коли подмали що потім це можна поправити і воно викатується на продакшн)
- #6 головні переваги і чому варто використовувати все білдиться автоматично білд теститься самостійно білд є доволі швидким білди ремонтуються дуже швидко кодний коміт білдить головну гілку на інтеграціїній машині
- #7 тести відбуваються в копії продакшина всі бачать які справи з білдом автоматиний деплой все міститься в одному ропозиторії всі комітять в голону гілку кожного дня легкий доступ до найновішого продукту Інтеграційні помилки виявляються на ранніх стадіях і легко відстежити через невеликі наборів змін. Це економить час і гроші протягом життя проекту. ящо виникають критичні помилки розробник завжди може відкотити проект назад через те що зміни були незначні Постійна наявність "поточного" білда для тестування, демо або релізу часта перевірка заставляє розробника робити модулі, і не робити їх надто складними велика кількість тестів допомагає воявити проблему на ранньому етапі
- #8 //головна ідеологія що все повинно виконуватись автоматично, сомоконтроль збірки проект білдиться з сорсів, з репозиторію. Ніяких проміжних і часткових замін, ніяких втручань з сторни користувача, ніяких редагувань файлів для зміни конфігурації проект можна пестити будь якими тестами: юніт, функціональними, продуктивності… Люди які відповідають за проект завжди в курсі всього що відбувається і хто в цьому винний
- #9 так виглядає вся робота CI перед білдом може мідбуваится перевірка коду на відповідність якимось правилам після білда також можуть бути якісь екшини, наприклад створення інсталера
- #10 я знаю що на своїх проектах дехто мав СІ є багато різних інструментів, як платних так і безплатних
- #11 все розширяється плагінами, все просто настроюється з допомогою if. Кожен крок окремо настроюється
- #16 Continuous delivery в основному логічне продовження Continuous Integration - це більш цілісне рішення, ніж C.I. так, як він містить набагато більше, ніж просто розробку програмного забезпечення. Постійна, успішна і повторювана методологія для деплою продукту автоматизаця кроків для перевірки коду і запуск його на продакшині
- #17 так виглядає весь процес CD. як я й говорив CD містить в собі СІ ci може тригирити різні stage машини з різними завданнями. App може диплоїтись на різні тестові машини для прогонки і провірки роботи застосунку. Це дає додаткову стабільніст для продукту (???? more about staging)
- #18 процес має бути повторювальним і надійним все має бути автоматично якщо щось скадне і болюче, робіть це частіше - це приведе до того що ви краще в цьому розбиретесь і в кінці кінців автоматизуєте все в репозиторії Done means “released”. Процес не буде завершений поки код не буде в користувача Build quality in! Блок тестового покриття, стиль коду, порушення правил, вимірювання складності Everybody has responsibility for the release process. Програма, що працює на ноутбуці розробників не заробить будь-які гроші для компанії. Аналогічним чином, проект без плану розвитку ніколи не будуть зарелізені, і знову не зароблять гроші. Компанії роблять гроші, надаючи продукти їх клієнтам, тому процес має бути цікавим для всіх. Кожен має думати про те як зробити продукт готовим для продажу Improve continuously. завжди вдосконалювати і підримувати
- #20 де можна хостити застосунки? на власних серверах, або використовувати клауди. підключатись по ssh і передавати всі необхідні файли Якщо on premises то можуть виникати деякі проблеми, наприклад якщо ми вокористовуємо iis і декілька сайтів хоститься на одній машині додатки не є ізольованими. Якщо нам потрібно хостити декілька одинакових додатків, і ми маємо одну машину виникають проблеми, або щось міняти або використовувати віртуальні машини.
- #21 але є рішення, яке дозволяє на одній машині хостити декілька додатків так ніби вони містяться на різних машинах
- #22 Фізичний сервер -> він має якусь OS -> Гипервизор (англ. Hypervisor) або Монітор віртуальних машин (в комп'ютерах) - програма або апаратна схема, що забезпечує або дозволяє одночасне, паралельне виконання декількох операційних систем на одному і тому ж хост-комп'ютері -> ядро віртуальної машини -> ліби необхідні для роботи -> сам застосунок на противагу doker Фізичний сервер -> він має якусь OS -> ліби необхідні для роботи -> сам застосунок це значно спрощеє роботу. з докер файлами легко процювати. Їх можна формуваит і переміщувати куди необхідно, заміна одного докер файла на інший відбувається майже миттєво. Докер це новий стандарт для хосту застосунків він з’явився не так дано 2013 рік, але активно набуває популярності. Зараз вже є можливість хостити doker контейнери на Amazone web services.
- #23 побудова нотейнера відбувається наступним чином в нас є докер файл який містить всю інформацію, це файл з всією конфігурацією там вказється що саме буде використовуватись, і що взагалі необхідно зробити. цей фал білдиться в image який містить OS, Soft, App коли заранити імідж ми отримаємо все робочий контейнер в якому крутитися аплікейшн
- #24 декілька слів про до devOps і взагалі чого я про них згадав
- #25 багато хто і я зокрема вважає що devOps це просто якийсь окремий процес який виконується в процесі розробки, або людина яка виконує якісь обов’язки. Але devops це зв’язкова ланка між розробкою, експлуатацією і ринком. Деякі команди самі інтегрують devOps, а є такі в яких спеціальна людина відповідає за налаштування всього зв’язку і автоматизації в розробці
- #26 це все процес для побудови якісного продукту
- #27 список практик, і за що відповідає DevOps