Frequent deliveries in a multi-team project by Roberts Luksa

2,686 views

Published on

Roberts works as a quality manager at odnoklassniki.ru. His responsibilities are release and test management, as well as new team members training and knowledge exchange support in the organization.

A talk about dealing with a short release cycle in a project, where different teams practise different development approaches. How and what to change to meet project growth, how to deliver in time, what specific roles are needed? An experience of a big project that can be useful for a growing team.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,686
On SlideShare
0
From Embeds
0
Number of Embeds
86
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Более 4 500 серверов в 4 датацентрахиспользуем Джаву, Гугл-Вэб-Тулкит, NOSQL базы данных, свой фрэймворк, своё решение для кэширования данных,
  • Представьте нашу обстановку:Команды обычно состоят из менеджера, пары тестировщиков и нескольких разработчиков, необязательно, что все находятся в одном офисе.Обновления, это то, что в разных компаниях называют по разному, delivery, live, релиз. Мы чаще всего это называем апдейтом.
  • Производственная необходимость – большой рост, инфраструктураЭкстренная необходимость – серьезные баги, спам
  • Вместе с ростом команды появилась как необходимость, так и возможность более быстро меняться. Как уже говорил, изменения происходили постепенно, расскажу о наиболее характерных детялях.
  • наиболее удобным для нас является недельный цикл апдейтов, и апдейт происходит во вторник. На самом деле, наиболее подходящие дни это вторник-четверг, т.к. понедельник не самый типичный день с точки зрения пользовательской активности, а пятница опасна тем, что там есть вечер пятницы, а иногда может потребоваться помощь ответственных.Сам цикл начинается со среды предыдущей недели. До понедельника постепенно собираются новые фичи и багфиксы, во вторник делается обновление, но до следующего обновления специально обученный дежурный разработчик в случае необходимости разбирает возникшие проблемы на продакшн-сайте.
  • Команда-1 – делает много небольших изменений по разным фичам (или от нескольких программистов), которые коммитит по мере готовностиКоманда-2 – 2-х недельный цикл разработки, в понедельник коммитят, в случае необходимости в этот же день исправляютКоманда-3 – недельный цикл разработки, коммитят (релизят) каждую пятницуКоманда-4 – разрабатывают что-то большое, до коммитов дело не дошло, работают в своем бранче.
  • можно выделить четыре основных этапа: вначале каждая команда разрабатывает фичу, которая должна пойти в апдейт,затем происходит интеграционное тестирование  на тестовой среде, максимально приближенной к реальной, после этого готовое обновление проверяется на тестовой группе или препродакшене - это группа продакшн серверов, на которых проходит "обкатка" и затем происходит обновление всего сайта.
  • Дальше уже начинается зона ответственности специальной команды конкретного обновления:дежурный разработчик просматривает все коммиты, чтобы быть в курсе всех будущих изменений на продакшене, зачастую он же делает ревью кода. Затем команда, делавшая коммит, тестирует функциональность, а после того, как были сделаны все изменения зависимых модулей проверяет, всё ли в норме. Критерием готовности является отсутствие незакрытых тасков и отсутствие неминорных проблем.
  • сервера, являющиеся частью продакшена, нос возможностью конфигурации, позволяющей работать или с новой, или со старой версией модулей.Каждый этап имеет чекпоинты - после сигнала о том, что можно тестировать, проходит регресс, главная задача, что ничего не сломано в процессе выкладки,как закончен ряд тестов, система вводится в ротацию - на нее заводятся реальные пользователи, создающие типичную нагрузку на сервер, несколько тысяч человек могут обнаружить что-то такое, что несколько десятков могли и не обнаружить. попадают на этот сервер случайным образом и для них нет разницы, что это какая-та "необычная"система. сравниваются определенные показатели (активность пользователей, время загрузки, рендеринг, всего около 20-30 показателей) характерных дней - текущий, на котором видны возможные изменения, предыдущй, как наиболее похожий, день предыдущего апдейта - неделя назад, на котором видны изменения именно в момент ввода в ротацию, который могут отличаться от типичной средней нагрузки. Показателем готовности будет отсутствие неожиданностейНе делаем апдейты по праздникам!
  • Обновление обычно начинается с более простых модулей с меньшим количеством зависимостей, параллельно развертыванию на все сервера происходит тестированиеЕсли в процессе выкладки находятся проблемы, то действуют согласно сложности и эффектуОсобенностью подхода является то, что все новые фичи обновления попадают на продакшн в выключенном виде (речь не идет об исправлении багов), это, с одной стороны, облегчает задачу по обновлению - после выкладки показатели работы сайта не должны измениться, не должно быть како-то повышенной активности или чего-то неожиданного из-за запущенного функционала. С другой стороны это вызывает необходимость или наоборот - возможность, запускать функциональность отдельно описанной процедурой
  • Запуск функциональности мы называем "экспериментом". Для него характерно, что обязательно должен быть понятен ожидаемый результат - подтверждение или опровержение какой-то гипотезы. Например, увеличение посещения того или иного раздела, или решение какой-то технической проблемы, ускорение загрузки. При запуске новой функциональности обязательно надо учитывать, на что это может повлиять, мониторить необходимую статистику, учитывать нагрузку и наблюдать за реакцией пользователей.
  • Вот основные инструменты которые мы используем. Для Сбора и анализа статистики мы используем свое решение, также у нас самописная и достаточно функциональная система управления, позволяющая как настройку отдельных параметров и запуск экспериментов, так и служащая инструментом выкладки обновления. Для баг и таск-трекинга мы используем Джиру и АтлассианКонфлуенс, как вики-систему обмена информацией.
  • Как таковой команды, которая занимается только обновлениями нет, но есть роли, которые нужны для любого апдейта. Дежурный разработчик это один из группы ведущих разработчиков, у которых есть опыт проведения апдейтов, которые хорошо знают систему и по очереди "дежурят" в обновлениях. Дежурный тестировщик это, на данный момент, любой из команды тестировщиков, т.к. они знают не только функциональность команды в которой они обычно работают, но и то, что и как можно и нельзя делать в любом другом месте. Системный администратор участвует только на этапе выкладки на продакшн и отвечает за то, что все будет работать нормально на всех серверах. Менеджер следит на тем, как соблюдаются и понятны ли принятые правила, нет ли проблем с передачей информации от этапа к этапу и организация команды на каждый из апдейтов.
  • Продуктовые команды, повторюсь, обычно состоят из менеджера, одного-двух тестировщиков и нескольких разработчиков. В некоторых случаем у команды есть свой "прикрепленный" дизайнер или сотрудник службы поддержки, специализирующийся на этой функциональности. Команда сама и разработчики и представители бизнеса - кроме них никто не знает ни как лучше сделать фичу, ни как она работает и будет развиваться. Поэтому они отвечают за нее полностью, не забывая, что все работают над одним продуктом - "одноклассниками".Каждая команда сама организовывает свою работу, нет каких-то строгих правил "сверху", главное - результат. В то же время есть общая культура компании, ряд правил, которые соблюдаются, но в то же время не являются чем-то выбитым в камне.
  • При таком подходе к организации работы команд и проведения обновлений у нас есть простые правила, которые являются определенным минимумом и не перегружают бюрократией. Частые регулярные обновления дают возможность планировать, зная, что и через неделю и через месяц не произойдет чего-то неожиданного, что помешает команде запустить новую фичу. Короткий цикл от идеи до первого запуска, без, например, необходимости написания тестов или согласования дают возможность быстро убедиться а нужно ли вообще пользователям то, что команда делает и в каком направлении двигаться.И самое главное, что разработчикам интересно!
  • Так же применяемый подход сравнительно легко масштабируется и корректируется. Приходится как переносить дни релиза, например из-за выходных, так и сокращать цикл и проводить два или три обновления в течение одной недели без особых проблем. Ответственность и самостоятельность команд позволяют как не тратить время на какой-то контроль, так и повышают качество, поскольку людям не всё равно, что они делают.
  • В некоторых случаях гибкие требования к командам или срокам вызывают желание "немножко нарушить", что в свою очередь вызывает такое же желание у коллег-программистов, в итоге "чуть-чуть" до коммита может вылиться в значительную задержку. Поэтому создаются рамки, в пределах которых допустимы какие-то отклонения, приоритет задач и эффект на пользователя - само-собой, что критические проблемы можно инужно решить в любое время.Гибкость в изменения цикла релизов может создать иллюзию, что если делать апдейт в два раза чаще, то на продакшене появится в два раза больше кода, но стоит помнить, что это зависит главным образом от команд разработки, а "уплотнить" их работу не так просто к тому же проведение обновления отнимает часть ресурсов этих же команд.Процесс обновления, как сервис для разработчиков может вызывать зависимость - поскольку он является своего рода черным ящиком - закоммитил, что-то внутри произошло, через какое-то время все уже работает на продакшене, то команды могут быть не заинтересованы повышать свою самостоятельность и класс, что важно для нас.
  • В ближайшее время мы как раз и двигаемся в направлении решения этих сложностей - даем возможность командам проводить самостоятельную выкладку своей функциональности, для этого ведутся работы по автоматизации - как процесса выкладки, так и увеличения покрытия автотестами.
  • апдейты проводятся без остановки работы сайтакоманды работают над продуктом самостоятельно и отвечают за свою функциональностьПланирование и формализация апдейтов дает свободу в выборе подхода и методологии разработки внутри команды. В определенных пределах, разумеется, с учетом, что у нас в любом случае разработка с частыми итерациями.Выделение ролей позволило более точно распределять задачи и ответственностьДумаю, наш опыт может пригодиться растущим командам, и показывает, что нет необходимости слепо использовать какие-то стандартные методологии, а постепенно адаптировать и применять действительно важные для себя подходы.
  • Frequent deliveries in a multi-team project by Roberts Luksa

    1. 1. Регулярные обновления в проекте с большим количеством команд Роберт Лукша odnoklassniki.ru
    2. 2. про Одноклассников
    3. 3. 33 000 000уникальных пользователей в день
    4. 4. 2 000 000 000 просмотров страниц в день
    5. 5. «Под капотом»Более 4 500 серверовJAVA, GWT, Cassandra, MS SQL,Zabbix ...
    6. 6. Контекст— Заказчик – мы сами— 3 офиса— 14 распределенных команд— Нужны частые обновления
    7. 7. Необходимость обновлений— Плановая разработка фич— Партнеры, промо-акции— Производственная необходимость— Экстренная необходимость
    8. 8. Эволюция
    9. 9. Раньше— Одна команда— Много срочных задач— Обновления по мере готовности фич— Участие всех разработчиков в процессе обновления— Апдейт – одна фича и несколько фиксов— Оффлайн-апдейт
    10. 10. Раньшеплюсы— готовый код выкладывался сразу же— высокая скорость работы— «атмосфера стартапа»минусы— остановки портала— тяжело выдержать ритм— в процесс обновления вовлечено много людей— высокий риск ошибок
    11. 11. Сейчас
    12. 12. Цикл обновленияпн вт ср чт пт сб вс пн вт ср чт пт сб вс пн вт ср чт пт сб всUPD-1 UPD-2 UPD-3 UPD-4
    13. 13. Командыпн вт ср чт пт сб вс пн вт ср чт пт сб вс пн вт ср чт пт сб всteam-1team-2team-3team-4
    14. 14. Подготовка обновления1. Разработка функциональности внутри команды2. Интеграция на тестовой среде3. Препродакшн4. Обновление продакшна
    15. 15. Разработка внутри команды1. Разработка фичи в бранче2. Функциональное и UI-тестирование на VM разработчик3. Ревью кода4. Коммит в мастер
    16. 16. Общая тестовая среда1. Коммиты в мастер2. Обновление на тестовой среде3. Тесты функциональности4. Интеграционное тестирование
    17. 17. Препродакшн1. Тестирование2. Ввод в ротацию3. Анализ (логи, графики, суппорт)⟳ При необходимости повторить
    18. 18. Процесс обновления1. Выкладка по модулям2. Тестирование3. Анализ – если всё плохо – откат – если просто плохо – фикс – если не очень хорошо – регистрация бага4. Информирование о замечаниях5. Ретроспектива
    19. 19. Запуск функциональностиПроведение «экспериментов» для запуска фич— ожидаемый результат— статистика— нагрузка— фидбэк от пользователей
    20. 20. Инструменты— своя система статистики— Portal Management System— GIT— Confluence— Jira
    21. 21. РолиДежурный разработчикДежурный тестировщикСистемный администраторМенеджер апдейта
    22. 22. Команды— Отвечают за фичу от дизайна до поддержки— Сами организовывают свою работу— Общая культура, но индивидуальный подход
    23. 23. Преимущества подхода— Простые и понятные правила— Предсказуемость планирования— Быстрый proof-of-concept— разработчикам интересно!
    24. 24. Чего добились— Адаптируемость подхода— Ответственность и самостоятельность команд— Программисты программируют— Тестировщики тестируют— Менеджеры поддерживают
    25. 25. «Грабли»— «еще 5 минут и закоммичу»— полегче с «уплотнением»— удобный сервис— зависимость от высококлассных специалистов
    26. 26. Скоро— Самостоятельные апдейты по необходимости— Автоматизация – выкладка – тестирование
    27. 27. Сейчас— Онлайн-апдейты— Разделение по командам— Апдейты по плану— Роли – дежурные – ответственные— Ревью кода— Формализация процесса обновления, но не разработки
    28. 28. Спасибоhttp://v.ok.ru/публикации Роберт Лукша ok.ru/rob roberts.luksa@odnoklassniki.ru

    ×