В докладе освещена ретроспектива организации разработки крупного интернет-проекта от стартапа до 190 миллионов пользователей.
Как устроена разработка сейчас, как в процессе развития проекта её перестраивали, какие проблемы решали,
преодолевая кризисы роста, на какие грабли наступали. В секции вопросов есть интересная информация о том, как в Badoo устроена
система мотивации и бонусов. Доклад будет интересен всем, кто занимается организацией процесса разработки в крупных интернет-проектах.
Доклад Алексея Рыбака на Whalerider 2013. Эволюция разработки в Badoo.
1. Эволюция разработки в Badoo
Рыбак Алексей
зам. главы разработки Badoo
a.rybak@corp.badoo.com
2. привет
Всего лишь ещё один рассказ о том, как
развивалась разработка в большом
проекте
Кризисы роста: области
ответственности, производственные
цепочки
Поделить/переделать, сохранив
ценности и пульс
3. Badoo
Социальная сеть для встречи с новыми людьми
190М users, ~30M MAU, ~10M DAU
Крупнейшие страны: Испания, Италия, Франция, Бразилия,
США
2 офиса разработки: Москва и Лондон
Миллионы строк кода, тысячи серверов, три датацентра
Стандартный стэк: Linux, nginx, PHP, MySQL, Memcached,
C/C++
100+ инженеров
4. Продуктовая интернет-компания
Программа в единственном экземпляре
Менее остро стоят вопросы совместимости ПО
и железа
Можно всё подбирать под себя и
подкручивать «на ходу»
6. От стартапа к продуктовой компании
Бизнес-инварианты
«Лёгкий» саппорт: разделение ответственности,
инфраструктурные проекты
Максимально быстрый цикл разработки при
сохранении качества: производственные цепочки
Проследим, как менялась разработка и сохранялись
инварианты
7. Кризисы роста
Кризис I: саппорт (10 – 20 чел, 2007)
Кризис II: дробление и новые роли в
организации (20 – 50 чел, 2009)
Кризис III: качество (QA) и перестройка
производственных цепочек (50 – 100+ чел,
2011)
8. Саппорт
Время программистов = время разработки продукта +
время на саппорт
Саппорт в широком смысле
• Поиск и мониторинг медленных/ненадежных мест
• Переделка архитектуры
• Инструменты для поддержки (мониторинг, деплой,
управление кластерами...)
• Инструменты для разработки (автоматизация,
ядро...)
9. Саппорт: отдельную команду не строим
Пахнет «штрафбатом»
Вовлеченность и мотивация сотрудников
Твой софт – твой крест
• Ты накосячил – ты и правь
• Нагрузка вырастет в «стопицот» раз, вокруг всё
миллион раз упадет, наш (твой!) софт должен это
пережить
• Пусть будут ошибки – давай быстро поправим,
просто не тупи и делай
11. Кризис II: дробление (2009?)
Оставить быстрым цикл разработки
Поделить команды функционально
Производственная цепочка по-прежнему
тривиальна: фигак-фигак, в продакшн!
Строим продуктовую команду
Не меняем сильно процессы, боимся сбить ритм
12. Кризис II: дробление
Фейл: как «не пошёл» Scrum
Функциональное дробление без перестройки
производственных цепочек
С/С++, фичи, биллинг, A-team, мобильная разработка,
бэк-офис, антиспам/почта
Проблемы: лиды, перераспределение зон
Фейл: позиции «магов»
Проблема: качество
Рекрутинг и HR, системный ревью зп
13. Кризис III: качество (2011)
Перестройка производственных цепочек
Отдел качества, release engineering
Девелоперская инфраструктура: площадка,
continuous integration, управление релизами, прочая
автоматизация
Перестройка без остановки разработки продукта: Ateam
Параллельно: строим QA/RE
14. Сейчас: статусы задач (фичи)
PRD <-> нет вопросов у программистов
Задача разбита по компонентам (микрокоманды)
Если нужно железо – есть сроки
Сопутствующие задачи (BI, мониторинг)
Код и тесты написаны, тесты прошли на девеле, ревью
QA passed
Переводы готовы (40 языков, ~10 основных)
RE: тесты на стейджинге, деплой
Деплой м.б. поэтапным: группа пользователей -> метрики -> везде
15. Кризис III: перестройка процессов
Подготовка в 2011, плотно - лишь в 2012 году
Деплой по фичам: svn -> git, «шоты» (фича) и «билды»
(релизы)
Девелоперская площадка: полная эмуляция 2х ДЦ и
базовых компонент
Утилиты деплоя и автоматизации, интеграция с JIRA,
доработка staging-инфраструктуры
Версионирование переводов
16. Кризис III: перестройка процессов
Строгий flow в JIRA + автоматизация
Unit-тесты: 22000 тестов за 3 минуты
Selenium-тесты: 500 тестов за 20 минут
2 релиза в день: утром и после обеда
Стогие стандарты кодирования, заголовки (модулькоманда-человек), покрытие кода
A-team -> передача сисадминам и релиз-инженерам
17. Выводы (1)
Методологии не очень существенны
Без фанатизма и сектанства. Waterfall? Пускай. Не
Agile? И что?
Выжили (не везде): backlogs, burn down charts,
stand-up meetings
18. Выводы (2)
Инфраструктурные проекты неизбежны
Технический долг: время разработки продукта ->
отдельная команда. A-team у нас – не DevOps
Без QA можно обходиться, и долго. Качество на
этапе релиза vs. качество в “продакшне” (ошибки,
мониторинг)
19. Выводы (3)
Неизбежность QA: рост по числу людей в
команде фич
Если строить QA – чем раньше, тем лучше
Перестройка цепочек – наиболее болезненные
процессы
С отдельной командой – лучше: очень много
сопутствующих задач