Continuous delivery continuous integration 0.3
•Transferir como PPTX, PDF•
2 gostaram•964 visualizações
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Continuous delivery continuous integration 0.3
Semelhante a Continuous delivery continuous integration 0.3 (20)
Mais de Alex Tregubov
Mais de Alex Tregubov (9)
Último
Último (20)
Continuous delivery continuous integration 0.3
- 2. IDEAS -> SOLUTIONS Time
- 6. CONTINUOUS DELIVERY Build the pipeline Keep software in One button deploy production ready state
- 7. 8 PRINCIPLES OF CONTINUOUS DELIVERY • The process for releasing/deploying software MUST be repeatable and reliable • Automate everything! • If something difficult or painful, do it more often • Keep everything in source control • Done means “released” • Build quality in! (Metrics) • Everybody has responsibility for the release process • Improve continuously
- 8. CONTINUOUS INTEGRATION VCS Remote Build Tests Checkout Repository
- 10. BUILD PIPELINE
- 11. CONTINUOUS DELIVERY Bug Feedback tracking system QA Build Sto- Dev VCS Stage server rage Prod. Smoke Feedback tests
- 12. DASHBOARD
- 13. CONTINUOUS DELIVERY EXAMPLE Load Balancer Auto Deploy Stage Production Auto Tests QA Engineers
- 14. CLOUD IS COOL Infrastructure as a code Pay as you go Ready for automation
- 15. CONTINUOUS DELIVERY IN CLOUD Demo Stage 1 Stage 2 Stage 3 Auto Tests QA Engineers
- 16. DEMO
- 17. OUR CONTACTS SpecialEPM-CITConsulting@epam.com http://cloud.epam.com https://twitter.com/EPAM_Cloud http://epamcloud.blogspot.com/ https://www.yammer.com/epam.com/ 17
Notas do Editor
- Начнём с проблемы: С момента возникновения идеи до её реализации часто проходит много времени.
- Каждый слышал пословицу «Время - деньги». Чем быстрее идея начинает работать в виде какой-либо реализации, тем больше профит она приносит.
- Если релизы делаются редко, то они выглядят как на картинке. Это нагромождение новых фитч, баг фиксов. Не понятно заработает ли это все на продакшене и в какие сроки можно будет все починить в случае фейла.Вы боитесь релизов? Ещё бы: это риск того, что ничего не будет работать и нужно будет долго и нудно разбираться, что именно, роясь в куче баг репортов, пересматривая тысячи строк. Например, часто релизы делаются в четверг, чтобы до вечера пятницы все пофиксить и не сидеть допоздна
- Первым принципом Agile-методологии являетсято, что первоочередная задача – это удовлетворение клиента по средствам Continuous Delivery.
- Continuous Delivery говорит о том, что нужно построить так называемый трубопровод, по которому софт, как конечный продукт, будет доставляться непрерывно заказчику либо пользователям.Чтобы это было возможно, ПО должно всегда быть готовым для продакшена, даже если не все фитчи реализованы. А для быстрого разворачивания софта используются системы, которые позволяют делать деплой в один клик.
- Continuous Integration – это часть процесса CD. Система автоматически по какому-либо триггеру делает check-out из системы контроля версий, собирает из исходников пакет/build, проводит автоматические тесты на локальном сервере (опционально) и кладёт этот билд в репозиторий (обычно это object-oriented storage, например амазонS3).Это важный момент для CD: билд делается всего один раз и потом, при деплое на любое окружение (будь то Stage, Demo, Prod etc),он (билд) берётся из централизованного репозитория.
- Существует множество CI серверов. Самые известные из них на слайде. Jenkins и CruiseControl – OpenSource. С помощью этих инструментов можно автоматизировать процесс сборки пакета и его доставки в environment.
- Так выглядит Build Pipeline в Jenkins-e. Для каждой версии показываются шаги сборки и визуально видно, что например версия 1.0 собралась успешно, а следующая уже зафейлилась на последнем этапе. Т.е. на раннем этапе мы видим, что что-то пошло не так и можем это исправить сразу же, а не ждать следующего релиза через месяц, когда выявить причину будет уже труднее.
- Итак, давайте разберём поэтапно весь процесс CD:Разработчики комитят код в VCS. Билд сервер по триггеру (время, кол-во комитов, по нажатию кнопки) собирает билд и проводит Smoke Tests (это автоматизированные тесты, которые выявляют самые грубые ошибки и ошибки, которые находятся на поверхности), таким образом мы получаем Early Fail, т.е. провал на раннем этапе и можем сразу же это исправить.Если Smoke Tests прошли успешно, то кладем билд в репозиторий.Затем из репозитория мы мрожемдеплоить его автоматически, по триггеру или руками на любой environment.
- Весь процесс отображается в виде графиков, истории релизов и т.д. Таким образом можно посмотреть, что при последнем релизе производительность приложения упала, например на 10%. Затем мы проверяем какие изменения в коде были сделаны. Т.к. релизы делаются часто, то изменений не много и мы находим очень быстро причину и исправляем её незамедлительно.
- Когда весь процесс CD настроен, то он может выглядеть следующим образом:Принимается решение, что билд можно залить на Stage-server. Выбираем версию, выбираем куда, нажимаем кнопку. Через некоторое время билд развёрнут на Stage. Его можно тестить, его можно показать заказчику и тд. Предположим, заказчик посмотрел реализацию фичи и она его немного не устраивает, он об этом сообщает и фитча немного допиливается. Потом новый релиз заливается на Stage и после approval от всех ответственных лиц можно просто переключить load balancer с Prod. на Stage. Причем делать это можно на гарячую, т.к. это абсолютно идентичные инфраструктуры связанные с одной БД или с разными, но между базами данных настроена репликация. Балансер настроен так, что он не обрывает сессии/транзакции, а перестают посылать новые на Prod и ждет, когда закончатся старые.Здесь может возникнуть отрицательный момент. Тесты могут блокировать друг друга и создавать очередь. Туту как раз и приходит на помощь облако, которое позволяет поднимать на нужное время любое количество идентичных окружений.
- Облако позволяет автоматизировать разворачивание инфраструктуры любой сложности.Так как с инфраструктурой можно работать как скодом. (API, CLI)И при этом мы платим только за ресурсы, которые мы использовали.
- Например для тестов релиза мы можем поднять 4 абсолютно идентичных окружения: для автотестов, для тестов со стороны QA, для нагрузочного тестирования и показать результат клиенту. И, как только в них исчезает необходимость, сразу их выключить.
- Optional. Можно показать как это все работает. Например: Jenkins, нажимаем кнопку, он собирает проект и кладёт его на Storage. Затем, используя Template, поднимается автоконфигурируемая инфраструктура, куда разворачивается наше приложение.Потом можно поменять строчку кода, закомитиь изменения в сиситему контроля версий, и повторить все. На этапе сборке происходит fail. Он исправляется, и все по новой но уже со счастливым концом.
- Это все, что я хотел рассказать в этой презентации. Больше информации вы можете найти по этим ссылкам.Спасибо за внимание, есть ли ко мне какие-либо вопросы?You can always come to us and ask questions, but we recommend you to use our Informational Portal first, it has answers to all Frequently Asked questions, integration with Management Console, Comprehensive help materials, Glossary and other valuable additions that will help you on your way to Self-Service model utilization.