- DevOps, # 2.5, Вокальная студия
Не секрет, что сама парадигма DevOps ориентирована на какую-либо конкретную платформу. Это может быть голый Linux, Kubernetis, AWS и т.д.
Для каждой платформы существуют свои инструменты с присущими им плюсами и минусами. Работая над серьезными проектами небольшим коллективом
мы выработали для себя набор практик, которые в дальнейшем воплотили в своё собственное Open Source решение. На примере нашего решения будут раскрыты
основные понятия, такие как:
- Замкнутый цикл разработка-тестирование-развертывание;
- Инфраструктура как код и её версионирование;
- Шаблоны развертывания;
- Изолированные контейнеризированные окружения;
- Программно-определяемая среда выполнения.
Для каждой платформы существуют свои инструменты с присущими им плюсами и минусами. Работая над серьезными проектами небольшим коллективом
мы выработали для себя набор практик, которые в дальнейшем воплотили в своё собственное Open Source решение. На примере нашего решения будут раскрыты
основные понятия, такие как:
- Замкнутый цикл разработка-тестирование-развертывание;
- Инфраструктура как код и её версионирование;
- Шаблоны развертывания;
- Изолированные контейнеризированные окружения;
- Программно-определяемая среда выполнения.
- DevOps, # 2.5, Вокальная студия
Хочу поделиться опытом построения процессов CI\CD в компании с нуля.
С проблемами, затронутыми в данном докладе, сталкивается любой админ знакомый со страшным словом "Релиз".
Расскажу наш путь перехода от Ctlc+C/Ctrl+V к HotDeploy.
С проблемами, затронутыми в данном докладе, сталкивается любой админ знакомый со страшным словом "Релиз".
Расскажу наш путь перехода от Ctlc+C/Ctrl+V к HotDeploy.
- DevOps, # 2.5, Вокальная студия
Доклад расскажет, зачем нужен DevOps-подход, существуют ли DevOps-инженеры, на что обратить внимание при внедрении DevOps, на какие технологии сегодня стоит обратить внимание. Чтобы все это не было скучно, доклад наполнен увлекательными примерами из опыта консалтинга «Экспресс 42».
- DevOps, # 2.5, Вокальная студия
- Мы — команда Трекера, которая сама использует свой сервис.
Задачи по разработке Трекера ведутся в нём самом, поэтому мы имеем возможность улучшать инструмент и этим улучшать собственные процессы.
- Проблема с “ненастоящим” скрамом: спринты есть, а скрама нет
У нас, как и у многих других, были спринты и встречи, похожие на описанные в Scrum Guide. Но скрам не работал. Расскажу, как мы его настроили.
- Проблема с потерей задач в процессе выполнения
Зачастую наши задачи повисали в промежуточных состояниях, например, в тестировании или "готовности к релизу", но не доезжали до продакшена.
- Организация скрам-команд: как ужиться фронтенду и бекенду? Как разрабатывать и тестировать фичу, затрагивающую несколько компонентов?
Специалисты разных типов должны работать вместе, чтобы выполнить задачу. Кроме того, при разработке могут понадобиться изменения в компонентах с разным релизным циклом: фронтенд, бекенд, библиотеки и т.д. Мы нашли удобное решение этих вопросов.
- Жизнь задачи: Как попасть в продакшен и не заблудиться?
Проблема с "зависшими" задачами и со сложным жизненным циклом решается удобным набором статусов задачи и переходов между ними. Расскажу про наш вариант.
- Организация ревью кода: как распределить задачи по ревьюверам? Что сделать, чтобы ревью заканчивалось в разумное время?
Организация ревью кода это не просто: сроки затягиваются, а разработчики в разной степени склонны проводить ревью. Мы пробовали разные варианты решения и автоматизировали их через Трекер, это помогло решить большую часть проблем.
- Git flow и его настройка под процесс, управление составом релизов, хотфиксы и откаты релизов.
Это может показаться банальным, но git flow действительно работает и приносит пользу. Однако, есть несколько близких вариантов его организации, и какой удобнее использовать — зависит от процессов в команде.
- Поддержка тестирования: Teamcity, docker и тестовые стенды
Teamcity настраивается гибко, а docker удобнее deb-пакетов. Расскажем, как это можно применить для поддержки тестирования.
- Проблемы со сложными релизами в нескольких окружениях, zero downtime релизы.
Каждый релиз каждого компонента должен деплоиться в несколько окружений. Мы научились избегать конфликта версий и не забывать об отдельных частях. И обновляться без перерыва в обслуживании при этом.
- Сервис для релизов и автоматизация
Любую рутину можно автоматизировать. Вот мы и сделали маленький инструмент для поддержки релизного цикла, а интеграция с Трекером позволила встроить его в процесс.
Задачи по разработке Трекера ведутся в нём самом, поэтому мы имеем возможность улучшать инструмент и этим улучшать собственные процессы.
- Проблема с “ненастоящим” скрамом: спринты есть, а скрама нет
У нас, как и у многих других, были спринты и встречи, похожие на описанные в Scrum Guide. Но скрам не работал. Расскажу, как мы его настроили.
- Проблема с потерей задач в процессе выполнения
Зачастую наши задачи повисали в промежуточных состояниях, например, в тестировании или "готовности к релизу", но не доезжали до продакшена.
- Организация скрам-команд: как ужиться фронтенду и бекенду? Как разрабатывать и тестировать фичу, затрагивающую несколько компонентов?
Специалисты разных типов должны работать вместе, чтобы выполнить задачу. Кроме того, при разработке могут понадобиться изменения в компонентах с разным релизным циклом: фронтенд, бекенд, библиотеки и т.д. Мы нашли удобное решение этих вопросов.
- Жизнь задачи: Как попасть в продакшен и не заблудиться?
Проблема с "зависшими" задачами и со сложным жизненным циклом решается удобным набором статусов задачи и переходов между ними. Расскажу про наш вариант.
- Организация ревью кода: как распределить задачи по ревьюверам? Что сделать, чтобы ревью заканчивалось в разумное время?
Организация ревью кода это не просто: сроки затягиваются, а разработчики в разной степени склонны проводить ревью. Мы пробовали разные варианты решения и автоматизировали их через Трекер, это помогло решить большую часть проблем.
- Git flow и его настройка под процесс, управление составом релизов, хотфиксы и откаты релизов.
Это может показаться банальным, но git flow действительно работает и приносит пользу. Однако, есть несколько близких вариантов его организации, и какой удобнее использовать — зависит от процессов в команде.
- Поддержка тестирования: Teamcity, docker и тестовые стенды
Teamcity настраивается гибко, а docker удобнее deb-пакетов. Расскажем, как это можно применить для поддержки тестирования.
- Проблемы со сложными релизами в нескольких окружениях, zero downtime релизы.
Каждый релиз каждого компонента должен деплоиться в несколько окружений. Мы научились избегать конфликта версий и не забывать об отдельных частях. И обновляться без перерыва в обслуживании при этом.
- Сервис для релизов и автоматизация
Любую рутину можно автоматизировать. Вот мы и сделали маленький инструмент для поддержки релизного цикла, а интеграция с Трекером позволила встроить его в процесс.