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