Реальный DevOps в энтерпрайзе / Александр Тараторин (Райффайзенбанк)Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 5 июня, 18:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2828.html
Что такое DevOps? Очередной модный термин? Методология? Набор инструментов? Культурные практики?
Для Райффайзенбанка DevOps - микс из всего перечисленного (смешать, но не взбалтывать!), применяемый чтобы:
- ускорить разработку и внедрение новых решений не в ущерб качеству;
- вовлечь админов в работу девелопмента;
- заинтересовать разработчиков жизнеспособностью их творений в реальной жизни.
...
SECON'2016 Евтухович Иван, Эксплуатация завтрашнего дня: от DevOps к NoOpsSECON
За последние годы у ИТ-сообщества накопился опыт использования систем управления конфигурацией и работой в организации по методологии DevOps. Но растущие вызовы показывают, что и этот подход имеет свои недостатки. Доклад расскажет о том, какие контейнеры бывают и почему они победят, что придет на смену облакам, и какие практики стоит начать внедрять сегодня, чтобы завтра не остаться без работы.
«DevOps — это о передаче смысла» — Александр Титов, Express 42DevDay
Текущим определением DevOps является аббревиатура CAMS:
— культура;
— автоматизация;
— измерения;
— распространение знаний.
Для меня это недостаточно понятно, я дополнил эти пункты тем, что DevOps это впервую очередь о передаче смысла без искажений. Я расскажу, как эти мысли соотносятся с методиками прошлого (ITIL, etc), как, используя такой подход, создать набор правил для работы и почему автоматизация — это не всегда хорошо.
Мы посмотрим как инструменты автоматизации помогают передавать смысл изменений между окружениями на примере реальных компонентов и кукбуков и рассмотрим на практике почему bash скрипты более слабый инструмент, чем Opscode Chef.
Совместно разберемся к требованиям к системе мониторинга. Что в системах мониторинга вредит передаче смысла, а что, наоборот, помогает. Какую систему мониторинга выбрать для вашего проекта?
Важность честности и открытости в команде для передачи смысла. Честные публичные пост-мортемы — это не проявление слабости, а проявление уважения к своим пользователям. Как научится делиться информацией друг с другом и не скрывать важного.
Модель системы Continuous Integration в компании Positive Technologies | Тиму...Positive Hack Days
1. Первоначальные типовые схемы, предлагаемые DevOps для всех проектов компании:
Build – Deploy – Testing – Promote
2. Реализация схемы на примерах наших проектов в TeamCity.
3. К чему мы пришли. Общая схема Continuous Integration:
Build – Deploy – Testing – Promote – Publishing – Delivery – Install & Update
DevOps и системы управления конфигурацией. SECON 2015Ivan Evtukhovich
Что такое DevOps, зачем он нужен, что включается в это понятие. Что такое Continuous Delivery, системы управления конфигурацией, сравнение Chef и Ansible.
Реальный DevOps в энтерпрайзе / Александр Тараторин (Райффайзенбанк)Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 5 июня, 18:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2828.html
Что такое DevOps? Очередной модный термин? Методология? Набор инструментов? Культурные практики?
Для Райффайзенбанка DevOps - микс из всего перечисленного (смешать, но не взбалтывать!), применяемый чтобы:
- ускорить разработку и внедрение новых решений не в ущерб качеству;
- вовлечь админов в работу девелопмента;
- заинтересовать разработчиков жизнеспособностью их творений в реальной жизни.
...
SECON'2016 Евтухович Иван, Эксплуатация завтрашнего дня: от DevOps к NoOpsSECON
За последние годы у ИТ-сообщества накопился опыт использования систем управления конфигурацией и работой в организации по методологии DevOps. Но растущие вызовы показывают, что и этот подход имеет свои недостатки. Доклад расскажет о том, какие контейнеры бывают и почему они победят, что придет на смену облакам, и какие практики стоит начать внедрять сегодня, чтобы завтра не остаться без работы.
«DevOps — это о передаче смысла» — Александр Титов, Express 42DevDay
Текущим определением DevOps является аббревиатура CAMS:
— культура;
— автоматизация;
— измерения;
— распространение знаний.
Для меня это недостаточно понятно, я дополнил эти пункты тем, что DevOps это впервую очередь о передаче смысла без искажений. Я расскажу, как эти мысли соотносятся с методиками прошлого (ITIL, etc), как, используя такой подход, создать набор правил для работы и почему автоматизация — это не всегда хорошо.
Мы посмотрим как инструменты автоматизации помогают передавать смысл изменений между окружениями на примере реальных компонентов и кукбуков и рассмотрим на практике почему bash скрипты более слабый инструмент, чем Opscode Chef.
Совместно разберемся к требованиям к системе мониторинга. Что в системах мониторинга вредит передаче смысла, а что, наоборот, помогает. Какую систему мониторинга выбрать для вашего проекта?
Важность честности и открытости в команде для передачи смысла. Честные публичные пост-мортемы — это не проявление слабости, а проявление уважения к своим пользователям. Как научится делиться информацией друг с другом и не скрывать важного.
Модель системы Continuous Integration в компании Positive Technologies | Тиму...Positive Hack Days
1. Первоначальные типовые схемы, предлагаемые DevOps для всех проектов компании:
Build – Deploy – Testing – Promote
2. Реализация схемы на примерах наших проектов в TeamCity.
3. К чему мы пришли. Общая схема Continuous Integration:
Build – Deploy – Testing – Promote – Publishing – Delivery – Install & Update
DevOps и системы управления конфигурацией. SECON 2015Ivan Evtukhovich
Что такое DevOps, зачем он нужен, что включается в это понятие. Что такое Continuous Delivery, системы управления конфигурацией, сравнение Chef и Ansible.
Прошло время, когда DevOps не был еще модным, началось время карго-культов и безбашенных внедрений. В докладе я расскажу про основные ошибки перехода компании к DevOps из моей практики, покажу как не надо использовать инструменты и как не надо организовывать команды, а также многое другое.
DevOps в Agile среде. Как, почему и когда инструменты помогают.Alexander Titov
Модное слово DevOps уже успело стать заезженным базвордом. Сотни компаний ищут DevOps инженеров, потому что искать системного администратора уже не модно. Я расскажу вам про свое понимание DevOps, как технические инструменты помогают делать Agile еще более гибким.
Мы разберем основные принципы DevOps через призму донесения смысла без потерь:
- Особая культура
- Автоматизация
- Изменения через измерения
- Распространение знаний и практик
Я поделюсь своим 5ти летним опытом в обеспечении повторяемости, мониторинге, логировании с примерами из реальной жизни.
Александр Титов - управляющий партнер в компании "Экспресс 42", мы внедряем DevOps практики и инструменты, помогаем эксплуатировать интернет-проекты.
В 2009, 2010 годах был техническим директором первого облачного хостинга в России Скалакси.
В 2010 - 2012 прошел увлекательный путь поглощений вместе с компанией Qik - путь из эксплуатации быстрорастущего стартапа к эксплуатации в крупной международной компании Microsoft.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Мифы о DevOps / Александр Титов, Иван Евтухович (Экспресс 42)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 10:00
Тезисы:
http://rootconf.ru/2017/abstracts/2830.html
Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.
Мы не хотим рассказывать, что такое DevOps, а расскажем о мифах, которые вредят пониманию. Их не так много, но важно о них знать, потому что эти мифы для вас будут маркерами неправильных управленческих и инженерных решений:
1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.
...
Agile мёртв (!|?) / Александр Сидоров (Яндекс)Ontico
Недавно вышла статья "Agile мёртв" (https://www.linkedin.com/pulse/agile-dead-matthew-kern).
Мне хотелось бы рассказать о том, почему, на мой взгляд, это признак взросления agile и отрасли IT в целом.
О том, почему agile могут называть мёртвым, как это может быть связано с ожиданиями и границами применения, а также о недостатках при внедрении и использовании, из-за которых agile-методологии могут быть дискредитированы и нарушать собственные принципы.
О том, чего касаются распространённые методологии, которые относят к agile, чего не описывают, а в чём могут вводить в заблуждение.
О том, в чём они полезны, где может быть их место в различных уровнях работы над проектами, какие отдельные инструменты и практики agile приживаются и приносят пользу, а также каких принципов полезно придерживаться при внедрении и работе с ними.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
Вебинар "Культура DevOps: основы эффективного взаимодействия IT-команд"Svyatoslav Vereshchak
Вебинар "Культура DevOps: основы эффективного взаимодействия IT-команд" состоялся 16 декабря 2014 года.
Темы:
– как зарождалась культура DevOps и что лежит в ее основе
– по каким качественным и количественным критериям оценивать эффективность IT-команд с точки зрения DevOps
– какие существуют типы корпоративных культур и как они влияют на IT-системы и коммуникации
– список самых популярных DevOps-инструментов
Информация о DevOps сообществе в России http://devopsru.com
Видеозапись вебинара http://www.youtube.com/watch?v=-T6FXE34ap0
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
JS Lab2017_Алексей Зеленюк_Сбалансированное окружение для вашей продуктивностиGeeksLab Odessa
JS Lab2017, 25 марта, Одесса
Алексей Зеленюк (Application Architect at Eleks Software)
Сбалансированное окружение для вашей продуктивности
Для построения больших веб-приложений необходим хороший фундамент: процесс сборки, тестирования и интеграции, анализа качества кода и отладки. Новые технологии и безнес-требования создают новые требования к окружению, усложняя его. Как построить надежное окружение, сохранив при этом его гибкость и простоту?
Прошло время, когда DevOps не был еще модным, началось время карго-культов и безбашенных внедрений. В докладе я расскажу про основные ошибки перехода компании к DevOps из моей практики, покажу как не надо использовать инструменты и как не надо организовывать команды, а также многое другое.
DevOps в Agile среде. Как, почему и когда инструменты помогают.Alexander Titov
Модное слово DevOps уже успело стать заезженным базвордом. Сотни компаний ищут DevOps инженеров, потому что искать системного администратора уже не модно. Я расскажу вам про свое понимание DevOps, как технические инструменты помогают делать Agile еще более гибким.
Мы разберем основные принципы DevOps через призму донесения смысла без потерь:
- Особая культура
- Автоматизация
- Изменения через измерения
- Распространение знаний и практик
Я поделюсь своим 5ти летним опытом в обеспечении повторяемости, мониторинге, логировании с примерами из реальной жизни.
Александр Титов - управляющий партнер в компании "Экспресс 42", мы внедряем DevOps практики и инструменты, помогаем эксплуатировать интернет-проекты.
В 2009, 2010 годах был техническим директором первого облачного хостинга в России Скалакси.
В 2010 - 2012 прошел увлекательный путь поглощений вместе с компанией Qik - путь из эксплуатации быстрорастущего стартапа к эксплуатации в крупной международной компании Microsoft.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Мифы о DevOps / Александр Титов, Иван Евтухович (Экспресс 42)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 10:00
Тезисы:
http://rootconf.ru/2017/abstracts/2830.html
Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.
Мы не хотим рассказывать, что такое DevOps, а расскажем о мифах, которые вредят пониманию. Их не так много, но важно о них знать, потому что эти мифы для вас будут маркерами неправильных управленческих и инженерных решений:
1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.
...
Agile мёртв (!|?) / Александр Сидоров (Яндекс)Ontico
Недавно вышла статья "Agile мёртв" (https://www.linkedin.com/pulse/agile-dead-matthew-kern).
Мне хотелось бы рассказать о том, почему, на мой взгляд, это признак взросления agile и отрасли IT в целом.
О том, почему agile могут называть мёртвым, как это может быть связано с ожиданиями и границами применения, а также о недостатках при внедрении и использовании, из-за которых agile-методологии могут быть дискредитированы и нарушать собственные принципы.
О том, чего касаются распространённые методологии, которые относят к agile, чего не описывают, а в чём могут вводить в заблуждение.
О том, в чём они полезны, где может быть их место в различных уровнях работы над проектами, какие отдельные инструменты и практики agile приживаются и приносят пользу, а также каких принципов полезно придерживаться при внедрении и работе с ними.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
Вебинар "Культура DevOps: основы эффективного взаимодействия IT-команд"Svyatoslav Vereshchak
Вебинар "Культура DevOps: основы эффективного взаимодействия IT-команд" состоялся 16 декабря 2014 года.
Темы:
– как зарождалась культура DevOps и что лежит в ее основе
– по каким качественным и количественным критериям оценивать эффективность IT-команд с точки зрения DevOps
– какие существуют типы корпоративных культур и как они влияют на IT-системы и коммуникации
– список самых популярных DevOps-инструментов
Информация о DevOps сообществе в России http://devopsru.com
Видеозапись вебинара http://www.youtube.com/watch?v=-T6FXE34ap0
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
JS Lab2017_Алексей Зеленюк_Сбалансированное окружение для вашей продуктивностиGeeksLab Odessa
JS Lab2017, 25 марта, Одесса
Алексей Зеленюк (Application Architect at Eleks Software)
Сбалансированное окружение для вашей продуктивности
Для построения больших веб-приложений необходим хороший фундамент: процесс сборки, тестирования и интеграции, анализа качества кода и отладки. Новые технологии и безнес-требования создают новые требования к окружению, усложняя его. Как построить надежное окружение, сохранив при этом его гибкость и простоту?
Развитие DevOps/NoOps инструментов. Что было, что есть, что будет.Ivan Evtukhovich
Доклад для конференции SQADays 20, обзорно рассказывает про DevOps, переход к NoOps и микросервисной архитектуре, а также почему ручное тестирование умрет.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Организация эффективной работы команды при разработке и поддержке сложной инф...tabtabus
Как поддерживать высокую скорость разработки без ущерба для качества кода? Как быстро и эффективно реагировать на проблемы, возникающие у пользователей? Как автоматизировать и упростить процесс обновления клиентских систем? Как обеспечить передачу знаний между сотрудниками? Как сделать работу сотрудников более интересной? Доклад дает ответы на эти и другие вопросы, основанные на более чем шестилетнем опыте разработки и поддержки сложной многозвенной информационной системы. В частности, рассматривается практический опыт внедрения таких приемов и методологий, как code review, парное программирование, test-driven development, continuous integration, автоматизированное тестирование пользовательского интерфейса, а также собственных наработок.
Agile Testing in Enterprise: Way to transform - SQA Days 2014Andrey Rebrov
This document discusses problems that can occur with traditional testing approaches and how to transition to agile testing practices. It provides two examples of organizations that struggled with long regression cycles, missed estimates, low quality and stress. The root causes are identified as document-based collaboration, lack of testing knowledge by developers, and infrastructure management chaos. Recommendations are made to use Kanban, collaborate on requirements, implement smart metrics, test automation, and a DevOps approach. Specific practices that were implemented include risk management, specification by example, test-driven development, continuous integration, configuration automation, and test automation. The results were increased delivery rates up to 5 times, zero bugs in production, no overtime, and more enjoyable work.
Spec By Example or How to teach people talk to each otherAndrey Rebrov
This document introduces an approach called "Spec By Example" to improve communication between developers, QA analysts, and clients. It involves impact mapping to focus on user stories, QA and analyst pairing to create examples to describe requirements, and diverse and merge sessions for the team to collaboratively build out examples. The examples are then optimized by compressing tables and introducing parameters before being linked to automated tests through a behavior driven development approach. This unified process allows requirements, test cases, and code to have a single source of truth, makes it easy to trace work back to business needs, and improves estimation, demos, and reduces rework and issues.
This document discusses test automation challenges at an investment bank and lessons learned. It outlines problems with lengthy manual regression testing. An attempt was made to use Jameleon for test automation but it caused issues. They identified needs for metrics, definitions of done, and separating test connections. Recommendations include using tools like Selenium and SoapUI with a Jenkins/JIRA setup. While quick wins are possible, separating test connections and fully defining requirements are important for successful test automation.
How engineering practices help businessAndrey Rebrov
This document provides advice on how to introduce new engineering practices and technologies to a team or business. It discusses several examples of proposed new practices and technologies such as test automation, continuous integration, refactoring, and DevOps. For each, it advises how to demonstrate the benefits through examples and metrics, how to gain buy-in from various stakeholders, and pitfalls to avoid such as claiming a practice is necessary just because a famous person recommends it. The overall message is that new practices must provide clear value and be introduced through demonstration and collaboration rather than dictates.
This document discusses using Logstash to collect, parse, and store logs from multiple sources in Elasticsearch. It describes Logstash's three main components - inputs, filters, and outputs. Examples are provided for using Logstash with Lumberjack to ship logs, parsing logs with grok filters, and outputting to Elasticsearch. Instructions are included for installing, configuring, and running Logstash, Elasticsearch, Kibana, and Lumberjack to build a log management pipeline.
This document discusses various DevOps tools and techniques including continuous integration, monitoring, logging, infrastructure as code, and visualization. For each tool or technique, it provides examples of how they can help teams as well as potential downsides related to communication issues. The key message is that while tools are useful, overreliance on tools without proper communication between team members can cause problems and that face-to-face conversations are important for addressing issues and improving processes.
The document discusses using business games to teach and promote Agile principles and practices. It defines what a business game is and notes they focus on results rather than process and involve more participant engagement than formal processes. The document outlines different types of business games for innovation, requirements analysis, and explaining Agile concepts. It provides recommendations for facilitating the games, such as not highlighting solutions and following the rules, and ideas for introducing Agile through a presentation and game with a success story. Resources for finding and creating additional business games are also included.
Automation Functional Testing in Agile ProjectsAndrey Rebrov
Об автоматических тестах писал ещё Сам Кент Бек. Ну, а автоматические функциональные тесты — это вообще лакомый кусок для современных agile методик разработки ПО. Вместе с участниками кемпа мы узнаем, с какой стороны подходить к процессу автоматизации тестирования в целом. Кроме того, мы создадим проект автотестирования с использованием одного из самых популярных продуктов для тестирования веб-приложений — Selenium 2.
18. DevOps
Manifesto
• Набор
ценностей
• Реакция
на
недостаток
коммуникаций
• Создание
отношений
между
dev
и
ops
• Работа
над
продуктом,
а
не
проектом
• …
hkp://bit.ly/devopsmanifesto
19. DevOps
-‐
это
не…
• Сертификация
• Роль
• Инструменты
• Прописанный
процесс
20. Чем
DevOps
отличается
от
Agile?
«Agile
сыграл
важную
роль
в
разработке
для
восстановлению
доверия
у
бизнеса,
но
он
нечаянно
оставил
IT
OperaQons
позади.
DevOps
это
способ
восстановления
доверия
ко
всей
ИТ-‐организации
в
целом»
Clyde
Logue,
основатель
StreamStep
21. Чем
DevOps
отличается
от
ITIL
и
ITSM?
DevOps
добавляет
в
ITIL
такие
пункты
как
настройка
сервисов,
управление
инцидентами
и
проблемами,
поскольку
цель
не
столько
увеличение
скорости
выдачи
нового
функционала,
сколько
развертывания
этого
функционала
в
производстве
без
хаоса.
23. Первый
путь
Производительность
всей
системы
в
целом,
в
отличие
от
производительности
отдельного
звена
или
отдела
—
это
может
быть
как
большое
подразделение
(например,
разработка
или
ИТ
отдел)
так
и
отдельные
люди
(например,
разработчик,
системный
администратор).
24. Второй
путь
Создании
цикла
обратной
связи
идущей
справа
налево.
Целью
практически
любой
инициативы
по
совершенствования
процесса
является
сокращение
и
усиление
обратной
связи,
чтобы
необходимые
поправки
могли
внедряться
постоянно.
25. Третий
путь
Создании
культуры,
которая
влияет
на
две
вещи:
постоянное
экспериментирование,
которое
требует
принятия
рисков
и
извлечение
уроков
из
успехов
и
неудач,
а
также
понимание
того,
что
повторения
и
практики
являются
предпосылкой
к
мастерству.
27. Антипаттерны
Devops
• Длинные
релизные
циклы
• Разногласия
между
Ops,
Dev,Dba,
Test,
...
• Работает
на
Stage
но
не
на
producQon.
• Долгая
подготовка
сред
для
поставки
• Ручное
обновление
конфигов
• Разнообразые
OS,
Middleware,
…
• Отсутствия
понимания
где
и
что
работает
• Ручное
документирование
28. И
еще…
• Разделенные
команды
• Раздробленные
системы
• Dependency
Hell
• Ручные
накаты
баз
данных
• Гигантские
Test
Datasets
• Тестирование
руками
• Релиз
руками
29. И
еще
чуть-‐чуть
• Неработающий
деплой
• Manual
Rollbacks
• Отсутствие
версионирования
• Code
Freezes
• …
30. 4
модели
внедрения
DevOps
Модель
1:
Углубление
процессов
разработки
в
поставку:
это
включает
расширение
непрерывной
интеграции
и
выпуска
в
на
боевые
сервера,
интеграция
тестирования
и
информзащиты
в
рабочие
процессы,
что
дает
готовый
к
поставке
код,
настроенные
среды,
и
так
далее.
31. 4
модели
внедрения
DevOps
Модель
2:
Создание
обратной
связи
от
прода
до
разработки:
включает
создание
полной
хронологии
событий
в
разработке
и
администрировании,
с
целью
помощи
в
разрешении
проблем,
а
так
же
предоставление
доступа
команде
разработки
к
анализу
проблем
на
проде,
одновременно
с
созданием
разработчиками
сервисов
самообслуживания,
везде
где
это
возможно,
и
создание
информационных
радиаторов,
показывающих
изменение
в
поведении
системы
при
вносе
изменений.
32. 4
модели
внедрения
DevOps
Модель
3:
Объединение
разработки
и
администрирования:
состоит
во
включении
команды
разработки
в
цепочку
разрешения
проблем,
назначение
разработчиков
на
разрешение
проблем
на
проде,
а
так
же
взаимные
тренинги
между
разработчиками
и
администраторами,
чтобы
уменьшить
количество
эскалаций.
33. 4
модели
внедрения
DevOps
Модель
4:
Включение
ИТ
команды
в
разработку:
состоит
во
включении
или
тесной
связью
между
IT
и
разработкой,
создание
многоэтапных
пользовательских
историй
(включая
развертывание,
управление
кодом
в
производстве
и
т.д.),
и
определение
нефункциональных
требования,
которые
могут
быть
использованы
во
всех
проектах.
42. Перекос
мотивации
• Senior
management
driven
by
total
revenue
• Sales
is
driven
by
compensaQon
• Development
is
driven
by
delivery
• Quality
Assurance
is
driven
by
defects
• OperaQons
is
driven
by
upQme
43. Non
FuncQonal
Requirements
• Security
• Backups
• Availability
and
Performance
• Upgrades
• ConfiguraQon
Management
• Monitoring
and
Logging
• Disaster
Recovery