CONTINUOUSDELIVERY /CONTINUOUSINTEGRATION
IDEAS -> SOLUTIONS                Time
TIME IS MONEY
TYPICAL RELEASE
AGILE MANIFESTO
CONTINUOUS DELIVERY    Build the pipeline  Keep software in                           One button deploy  production ready ...
8 PRINCIPLES OF CONTINUOUS DELIVERY• The process for releasing/deploying software MUST be repeatable  and reliable• Automa...
CONTINUOUS INTEGRATION     VCS                       Remote              Build   Tests   Checkout                   Reposi...
CONTINUOUS INTEGRATION TOOLS
BUILD PIPELINE
CONTINUOUS DELIVERY                                          Bug                    Feedback           tracking           ...
DASHBOARD
CONTINUOUS DELIVERY EXAMPLE                                     Load Balancer      Auto Deploy            Stage           ...
CLOUD IS COOL                Infrastructure as a code      Pay as you go                        Ready for automation
CONTINUOUS DELIVERY IN CLOUD                      Demo        Stage 1     Stage 2      Stage 3       Auto Tests        QA ...
DEMO
OUR CONTACTS        SpecialEPM-CITConsulting@epam.com        http://cloud.epam.com        https://twitter.com/EPAM_Cloud  ...
Upcoming SlideShare
Loading in...5
×

Continuous delivery continuous integration 0.3

758

Published on

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
758
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Начнём с проблемы: С момента возникновения идеи до её реализации часто проходит много времени.
  • Каждый слышал пословицу «Время - деньги». Чем быстрее идея начинает работать в виде какой-либо реализации, тем больше профит она приносит.
  • Если релизы делаются редко, то они выглядят как на картинке. Это нагромождение новых фитч, баг фиксов. Не понятно заработает ли это все на продакшене и в какие сроки можно будет все починить в случае фейла.Вы боитесь релизов? Ещё бы: это риск того, что ничего не будет работать и нужно будет долго и нудно разбираться, что именно, роясь в куче баг репортов, пересматривая тысячи строк. Например, часто релизы делаются в четверг, чтобы до вечера пятницы все пофиксить и не сидеть допоздна 
  • Первым принципом 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.
  • Continuous delivery continuous integration 0.3

    1. 1. CONTINUOUSDELIVERY /CONTINUOUSINTEGRATION
    2. 2. IDEAS -> SOLUTIONS Time
    3. 3. TIME IS MONEY
    4. 4. TYPICAL RELEASE
    5. 5. AGILE MANIFESTO
    6. 6. CONTINUOUS DELIVERY Build the pipeline Keep software in One button deploy production ready state
    7. 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. 8. CONTINUOUS INTEGRATION VCS Remote Build Tests Checkout Repository
    9. 9. CONTINUOUS INTEGRATION TOOLS
    10. 10. BUILD PIPELINE
    11. 11. CONTINUOUS DELIVERY Bug Feedback tracking system QA Build Sto- Dev VCS Stage server rage Prod. Smoke Feedback tests
    12. 12. DASHBOARD
    13. 13. CONTINUOUS DELIVERY EXAMPLE Load Balancer Auto Deploy Stage Production Auto Tests QA Engineers
    14. 14. CLOUD IS COOL Infrastructure as a code Pay as you go Ready for automation
    15. 15. CONTINUOUS DELIVERY IN CLOUD Demo Stage 1 Stage 2 Stage 3 Auto Tests QA Engineers
    16. 16. DEMO
    17. 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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×