• DevOps, # 2.5, Вокальная студия

Бекенд-разработчик Яндекс.Трекера с 2015. Java, много devops-активностей, скрам До этого десять лет опыта с другими технологиями, компаниями и подходами.

- Мы — команда Трекера, которая сама использует свой сервис.
Задачи по разработке Трекера ведутся в нём самом, поэтому мы имеем возможность улучшать инструмент и этим улучшать собственные процессы.
- Проблема с “ненастоящим” скрамом: спринты есть, а скрама нет
У нас, как и у многих других, были спринты и встречи, похожие на описанные в Scrum Guide. Но скрам не работал. Расскажу, как мы его настроили.
- Проблема с потерей задач в процессе выполнения
Зачастую наши задачи повисали в промежуточных состояниях, например, в тестировании или "готовности к релизу", но не доезжали до продакшена.
- Организация скрам-команд: как ужиться фронтенду и бекенду? Как разрабатывать и тестировать фичу, затрагивающую несколько компонентов?
Специалисты разных типов должны работать вместе, чтобы выполнить задачу. Кроме того, при разработке могут понадобиться изменения в компонентах с разным релизным циклом: фронтенд, бекенд, библиотеки и т.д. Мы нашли удобное решение этих вопросов.
- Жизнь задачи: Как попасть в продакшен и не заблудиться?
Проблема с "зависшими" задачами и со сложным жизненным циклом решается удобным набором статусов задачи и переходов между ними. Расскажу про наш вариант.
- Организация ревью кода: как распределить задачи по ревьюверам? Что сделать, чтобы ревью заканчивалось в разумное время?
Организация ревью кода это не просто: сроки затягиваются, а разработчики в разной степени склонны проводить ревью. Мы пробовали разные варианты решения и автоматизировали их через Трекер, это помогло решить большую часть проблем.
- Git flow и его настройка под процесс, управление составом релизов, хотфиксы и откаты релизов.
Это может показаться банальным, но git flow действительно работает и приносит пользу. Однако, есть несколько близких вариантов его организации, и какой удобнее использовать — зависит от процессов в команде.
- Поддержка тестирования: Teamcity, docker и тестовые стенды
Teamcity настраивается гибко, а docker удобнее deb-пакетов. Расскажем, как это можно применить для поддержки тестирования.
- Проблемы со сложными релизами в нескольких окружениях, zero downtime релизы.
Каждый релиз каждого компонента должен деплоиться в несколько окружений. Мы научились избегать конфликта версий и не забывать об отдельных частях. И обновляться без перерыва в обслуживании при этом.
- Сервис для релизов и автоматизация
Любую рутину можно автоматизировать. Вот мы и сделали маленький инструмент для поддержки релизного цикла, а интеграция с Трекером позволила встроить его в процесс.

Может быть интересно любому, кто беспокоится о процессах в своей команде.