Релиз Процесс
•
0 likes•133 views
О том как и зачем мы перешли от “фигак-фигак и в продакшен” к более формальному подходу к обновлению прода. А также как это повлияло на частоту релизов (спойлер: их стало больше).
Report
Share
Report
Share
Download to read offline
Recommended
Путь мониторинга: модульность, гибкость, devops
Доклад на rootconf концеренции, о том как мы в grammarly устроили мониторинг на базе influx, graphite, sensu, statsd, logstash
Путь мониторинга: модульность, гибкость, devops / Всеволод Поляков (Grammarly)
Почти год назад мы завершили проект по универсальному мониторингу и в процессе приобрели кучу секретных знаний и умений, которыми хотим поделиться:
* как сделать мониторинг простым, отказоустойчивым и горизонтально масштабируемым;
* как понять, что важно, что не важно, а что важно, но чуть-чуть;
* полезные логи: конвертация логов в метрики и обратно;
* как диагностировать реальные проблемы и отличить их от ложной тревоги (на примере связки js-фронтенд + балансеры + java-бэкенд);
* и, конечно же, как внедрить практики DevOps посредством мониторинга (и подготовить разработчиков к тому, что они ответственны за алерты).
Стек мониторинга: sensu, graphite, cassandra, logstash, heka, influxdb, elsticsearch, chef, statsd, nginx.
Стек поддержки: js, java, erlang, lisp, python, ruby, nginx, mysql, haproxy
Chef wtf
KyivOps #0 at Ciklum, Sep 26, 2015
A story about why we in Grammarly abandoned development chef, as a configuration management system.
«GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков
Особенности модели Github-flow и нюансы её внедрения в основную ветку разработки.
DevOps для 1С
адаптация модели DevOps и модели инженеров бизнес-приложения для технологического стека 1С Предприятие. Infostart Connect 2015
Recommended
Путь мониторинга: модульность, гибкость, devops
Доклад на rootconf концеренции, о том как мы в grammarly устроили мониторинг на базе influx, graphite, sensu, statsd, logstash
Путь мониторинга: модульность, гибкость, devops / Всеволод Поляков (Grammarly)
Почти год назад мы завершили проект по универсальному мониторингу и в процессе приобрели кучу секретных знаний и умений, которыми хотим поделиться:
* как сделать мониторинг простым, отказоустойчивым и горизонтально масштабируемым;
* как понять, что важно, что не важно, а что важно, но чуть-чуть;
* полезные логи: конвертация логов в метрики и обратно;
* как диагностировать реальные проблемы и отличить их от ложной тревоги (на примере связки js-фронтенд + балансеры + java-бэкенд);
* и, конечно же, как внедрить практики DevOps посредством мониторинга (и подготовить разработчиков к тому, что они ответственны за алерты).
Стек мониторинга: sensu, graphite, cassandra, logstash, heka, influxdb, elsticsearch, chef, statsd, nginx.
Стек поддержки: js, java, erlang, lisp, python, ruby, nginx, mysql, haproxy
Chef wtf
KyivOps #0 at Ciklum, Sep 26, 2015
A story about why we in Grammarly abandoned development chef, as a configuration management system.
«GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков
Особенности модели Github-flow и нюансы её внедрения в основную ветку разработки.
DevOps для 1С
адаптация модели DevOps и модели инженеров бизнес-приложения для технологического стека 1С Предприятие. Infostart Connect 2015
Cтатические анализаторы систем 1с AgileDays 2015
Доклад на AgileDays2015 о способах оценки качества метаданных 1С с помощью OpenSource инструментария
Адаптация Git flow при коллективной разработке на 1с
Немного о философии GIT-FLOW применительно к 1С разработке
Автоматическая сборка и развертывание на платформе 1C
1. Непрерывная интеграция функционала. Методическая практика развертыванияпродукта. Блоки работ необходимые к проведению в рамках передачи релиза конфигурации в production эксплуатацию. Методические рекомендации фирмы 1С по подготовке продукта к непрерывной интеграции.
2. Способы реализации этапов непрерывной интеграции функционала на платформе 1С и сервере непрерывной интеграции
3. Особенности прохождения этапов сборки и развертывания в зависимости от типа задачи - исправление ошибок, изменение кода, изменение структуры метаданных и т.д.
4. Типовые недочеты и способы их исправления в рамках автоматизированной сборки продукта и его последующего развертывания. Типовые сценарии отката развернутой функциональности
Развитие навыков 1с специалиста до 5 го уровня
Презентация к прямому эфиру по концепции куба качества и развития навыков
Доклад Владислава Чернова & Олега Оямяэ на РИТ++ 2013. "AIDA. Непрерывная инт...
В крупном интернет проекте при построении непрерывной интеграции возникает множество проблем и рутинной работы. Этот доклад о том, как мы избежали проблем и автоматизировали большую часть работы. Мы показали связь непрерывной интеграции со всеми стадиями разработки программного продукта.
А также вы узнаете из доклада:
1. Модель разработки каждой задаче в отдельной ветке, плюсы и минусы.
2. Как автоматизировать рутинные операции в системе контроля версий.
3. Организации работы с хуками в Git в условиях большого количества репозиториев.
4. Автоматизация работы с баг трекером, как у нас проходит ревью кода.
5. Построение непрерывной интеграции для компилируемых и не компилируемых компонентов.
6. Автоматизация сборок с зависимостями из веток релиза для компилируемых компонент.
7. Continuous delivery и почему большое количество веток не всегда плохое решение для данного подхода.
И конечно же Release engineering, как он влияет на разработку и качество продукта.
После доклады вы поймете все основные процессы при построении непрерывной интеграции и увидите как важна автоматизация в данном процессе.
Continuous delivery в крупном интернет проекте
Презентация доклада Владислава Чернова на конференции SQADays-14, Львов 8-9 ноября 2013
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
Continuous Delivery, или волшебная кнопка для релизов по запросу, Денис Яковл...
Доклад Дениса Яковлева на HighLoad++ 2014.
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС
Если наш проект это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готово кода в боевое окружение. В самом начале, когда наш проект маленький и простой на эту задачу никто может и не обращать внимание, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов - git pull, yii migrate, etc...которые легко запомнить и в которых сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилититы, библиотеки и т.д.), новые сущности (балансеры, кешы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем чем решений, люди ошибаются чаще и т.д.
В докладе:
— Рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты.
— Обсудим какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, в чем их задача и какое решение выбрать;
— Поговорим про административные вопросы, которые с этим связаны.
Мертвая зона - Как визуализировать поток требований в распределенном проекте
Сергей Прохоренко, Luxoft (Киев)
Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?
Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.
Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.
SECON'2017, Кулагин Егор, Непрерывное развертывание. Конвейер здорового челов...
SECON'2017 | 21-22 апреля
Платформа для поставки счастья в команду QA
Слайды с выступления с конференции Rootconf ( РИТ фестиваль ).
Github Flow. Тестировщики против тестирования
Презентация Татьяны Писчасовой на SQA Days-16
14-15 ноября 2014, Санкт-Петербург, Россия
www.sqadays.com
More Related Content
What's hot
Cтатические анализаторы систем 1с AgileDays 2015
Доклад на AgileDays2015 о способах оценки качества метаданных 1С с помощью OpenSource инструментария
Адаптация Git flow при коллективной разработке на 1с
Немного о философии GIT-FLOW применительно к 1С разработке
Автоматическая сборка и развертывание на платформе 1C
1. Непрерывная интеграция функционала. Методическая практика развертыванияпродукта. Блоки работ необходимые к проведению в рамках передачи релиза конфигурации в production эксплуатацию. Методические рекомендации фирмы 1С по подготовке продукта к непрерывной интеграции.
2. Способы реализации этапов непрерывной интеграции функционала на платформе 1С и сервере непрерывной интеграции
3. Особенности прохождения этапов сборки и развертывания в зависимости от типа задачи - исправление ошибок, изменение кода, изменение структуры метаданных и т.д.
4. Типовые недочеты и способы их исправления в рамках автоматизированной сборки продукта и его последующего развертывания. Типовые сценарии отката развернутой функциональности
Развитие навыков 1с специалиста до 5 го уровня
Презентация к прямому эфиру по концепции куба качества и развития навыков
Доклад Владислава Чернова & Олега Оямяэ на РИТ++ 2013. "AIDA. Непрерывная инт...
В крупном интернет проекте при построении непрерывной интеграции возникает множество проблем и рутинной работы. Этот доклад о том, как мы избежали проблем и автоматизировали большую часть работы. Мы показали связь непрерывной интеграции со всеми стадиями разработки программного продукта.
А также вы узнаете из доклада:
1. Модель разработки каждой задаче в отдельной ветке, плюсы и минусы.
2. Как автоматизировать рутинные операции в системе контроля версий.
3. Организации работы с хуками в Git в условиях большого количества репозиториев.
4. Автоматизация работы с баг трекером, как у нас проходит ревью кода.
5. Построение непрерывной интеграции для компилируемых и не компилируемых компонентов.
6. Автоматизация сборок с зависимостями из веток релиза для компилируемых компонент.
7. Continuous delivery и почему большое количество веток не всегда плохое решение для данного подхода.
И конечно же Release engineering, как он влияет на разработку и качество продукта.
После доклады вы поймете все основные процессы при построении непрерывной интеграции и увидите как важна автоматизация в данном процессе.
Continuous delivery в крупном интернет проекте
Презентация доклада Владислава Чернова на конференции SQADays-14, Львов 8-9 ноября 2013
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
Continuous Delivery, или волшебная кнопка для релизов по запросу, Денис Яковл...
Доклад Дениса Яковлева на HighLoad++ 2014.
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС
Если наш проект это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готово кода в боевое окружение. В самом начале, когда наш проект маленький и простой на эту задачу никто может и не обращать внимание, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов - git pull, yii migrate, etc...которые легко запомнить и в которых сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилититы, библиотеки и т.д.), новые сущности (балансеры, кешы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем чем решений, люди ошибаются чаще и т.д.
В докладе:
— Рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты.
— Обсудим какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, в чем их задача и какое решение выбрать;
— Поговорим про административные вопросы, которые с этим связаны.
Мертвая зона - Как визуализировать поток требований в распределенном проекте
Сергей Прохоренко, Luxoft (Киев)
Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?
Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.
Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.
SECON'2017, Кулагин Егор, Непрерывное развертывание. Конвейер здорового челов...
SECON'2017 | 21-22 апреля
Платформа для поставки счастья в команду QA
Слайды с выступления с конференции Rootconf ( РИТ фестиваль ).
Github Flow. Тестировщики против тестирования
Презентация Татьяны Писчасовой на SQA Days-16
14-15 ноября 2014, Санкт-Петербург, Россия
www.sqadays.com
What's hot (19)
Адаптация Git flow при коллективной разработке на 1с
Адаптация Git flow при коллективной разработке на 1с
Автоматическая сборка и развертывание на платформе 1C
Автоматическая сборка и развертывание на платформе 1C
Доклад Владислава Чернова & Олега Оямяэ на РИТ++ 2013. "AIDA. Непрерывная инт...
Доклад Владислава Чернова & Олега Оямяэ на РИТ++ 2013. "AIDA. Непрерывная инт...
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac
Continuous Delivery, или волшебная кнопка для релизов по запросу, Денис Яковл...
Continuous Delivery, или волшебная кнопка для релизов по запросу, Денис Яковл...
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС
Мертвая зона - Как визуализировать поток требований в распределенном проекте
Мертвая зона - Как визуализировать поток требований в распределенном проекте
SECON'2017, Кулагин Егор, Непрерывное развертывание. Конвейер здорового челов...
SECON'2017, Кулагин Егор, Непрерывное развертывание. Конвейер здорового челов...
Инженерный дзен. Непрерывные изменения (Александр Титов)
Инженерный дзен. Непрерывные изменения (Александр Титов)
Релиз Процесс
- 3. Status Quo • Как только, так сразу • Несколько команд • Один код • “Зачем ты запушил, я собирался релизить!” • Хорошо если раз в две недели
- 4. Запросы • А это было задеплоено? • А когда? • А что задеплоено вместе с этим? • Мы хотим релиз нотс!
- 5. Цели • Что было задеплоено когда • Минимум изменений за раз • Максимум автоматизации • Децентрализация
- 6. Учет релизов • Проект в JIRA • В каждом тикете: платформа, команда, список изменений • Ready for Deploy во всех проектах
- 9. Внедрение • Автоматизация • Владение мастером • Release vs Hotfix • Approvals
- 11. • 38 релизов за последние 30 дней • 5 приложений • 9 команд Platform TypeTeam
- 12. Q&A
- 13. Спасибо!