Successfully reported this slideshow.

Алексей Рыбак (Badoo)

1,096 views

Published on

Whale Rider 2013

  • Be the first to comment

Алексей Рыбак (Badoo)

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

×