Эволюция разработки в Badoo

Рыбак Алексейзам. главы разработки Badoo

a.rybak@corp.badoo.com

приветВсего лишь ещё один рассказ о том, как

развивалась разработка в большом проекте

Кризисы роста: области ответственности, производственные цепочки

Поделить/переделать, сохранив ценности и пульс

Badoo Социальная сеть для встречи с новыми людьми

190М users, ~30M MAU, ~10M DAU

Крупнейшие страны: Испания, Италия, Франция, Бразилия, США

2 офиса разработки: Москва и Лондон

Миллионы строк кода, тысячи серверов, три датацентра

Стандартный стэк: Linux, nginx, PHP, MySQL, Memcached, C/C++

100+ инженеров

Продуктовая интернет-компания

Программа в единственном экземпляреМенее остро стоят вопросы совместимости ПО

и железаМожно всё подбирать под себя и

подкручивать «на ходу»

Ценности продуктового стартапа

Быстрый либо мёртвый

Экспериментируем, скорость в ущерб качеству

24х7, «легкий» саппорт

От стартапа к продуктовой компании

Бизнес-инварианты«Лёгкий» саппорт: разделение ответственности,

инфраструктурные проектыМаксимально быстрый цикл разработки при

сохранении качества: производственные цепочкиПроследим, как менялась разработка и сохранялись

инварианты

Кризисы роста

Кризис I: саппорт (10 – 20 чел, 2007)

Кризис II: дробление и новые роли в организации (20 – 50 чел, 2009)

Кризис III: качество (QA) и перестройка производственных цепочек (50 – 100+ чел, 2011)

СаппортВремя программистов = время разработки продукта +

время на саппорт

Саппорт в широком смысле

• Поиск и мониторинг медленных/ненадежных мест• Переделка архитектуры• Инструменты для поддержки (мониторинг, деплой,

управление кластерами...)• Инструменты для разработки (автоматизация,

ядро...)

Саппорт: отдельную команду не строимПахнет «штрафбатом»

Вовлеченность и мотивация сотрудников

Твой софт – твой крест

• Ты накосячил – ты и правь• Нагрузка вырастет в «стопицот» раз, вокруг всё

миллион раз упадет, наш (твой!) софт должен это пережить• Пусть будут ошибки – давай быстро поправим,

просто не тупи и делай

Кризис I: саппорт (2007)Отдельное направление: производительность,

надежность, мониторингФейл: общие ресурсыФикс:

• A-team + C/C++ = Platform (инфраструктурные проекты)• Рост группы сисадминов/эксплуатации

Кризис II: дробление (2009?)

Оставить быстрым цикл разработкиПоделить команды функциональноПроизводственная цепочка по-прежнему

тривиальна: фигак-фигак, в продакшн!Строим продуктовую командуНе меняем сильно процессы, боимся сбить ритм

Фейл: как «не пошёл» Scrum

Функциональное дробление без перестройки производственных цепочек

С/С++, фичи, биллинг, A-team, мобильная разработка, бэк-офис, антиспам/почта

Проблемы: лиды, перераспределение зон

Фейл: позиции «магов»

Проблема: качество

Рекрутинг и HR, системный ревью зп

Кризис II: дробление

Кризис III: качество (2011)Перестройка производственных цепочекОтдел качества, release engineeringДевелоперская инфраструктура: площадка,

continuous integration, управление релизами, прочая автоматизация

Перестройка без остановки разработки продукта: A-team

Параллельно: строим QA/RE

Сейчас: статусы задач (фичи) PRD <-> нет вопросов у программистов

Задача разбита по компонентам (микрокоманды)

Если нужно железо – есть сроки

Сопутствующие задачи (BI, мониторинг)

Код и тесты написаны, тесты прошли на девеле, ревью

QA passed

Переводы готовы (40 языков, ~10 основных)

RE: тесты на стейджинге, деплой

Деплой м.б. поэтапным: группа пользователей -> метрики -> везде

Кризис III: перестройка процессов

Подготовка в 2011, плотно - лишь в 2012 году

Деплой по фичам: svn -> git, «шоты» (фича) и «билды» (релизы)

Девелоперская площадка: полная эмуляция 2х ДЦ и базовых компонент

Утилиты деплоя и автоматизации, интеграция с JIRA, доработка staging-инфраструктуры

Версионирование переводов

Кризис III: перестройка процессов

Строгий flow в JIRA + автоматизация

Unit-тесты: 22000 тестов за 3 минуты

Selenium-тесты: 500 тестов за 20 минут

2 релиза в день: утром и после обеда

Стогие стандарты кодирования, заголовки (модуль-команда-человек), покрытие кода

A-team -> передача сисадминам и релиз-инженерам

Выводы (1)

Методологии не очень существенныБез фанатизма и сектанства. Waterfall? Пускай. Не

Agile? И что?Выжили (не везде): backlogs, burn down charts,

stand-up meetings

Выводы (2)

Инфраструктурные проекты неизбежныТехнический долг: время разработки продукта ->

отдельная команда. A-team у нас – не DevOpsБез QA можно обходиться, и долго. Качество на

этапе релиза vs. качество в “продакшне” (ошибки, мониторинг)

Выводы (3)Неизбежность QA: рост по числу людей в

команде фич

Если строить QA – чем раньше, тем лучшеПерестройка цепочек – наиболее болезненные

процессы

С отдельной командой – лучше: очень много сопутствующих задач

Спасибо!

Ваши вопросы, пожалуйста!a.rybak@corp.badoo.comhttp://habrahabr.ru/company/badoohttp://facebook.com/BadooMoscowhttp://twitter.com/BadooDev