company_banner

Процесс разработки в Badoo

    Сегодня мы проведём экскурсию по цеху разработки Badoo, в котором создаётся новый функционал нашего сайта, расскажем о самом процессе — от постановки задачи и до момента выкладки в боевое окружение.

    За время существования компании её рабочий процесс эволюционировал от стохастического к хорошо контролируемому и понятному. Ещё полтора-два года назад никто точно не мог ответить на вопрос, какие задачи попали в сегодняшнюю выкладку, а менеджер опрашивал программистов, кто и что выложил. Сейчас же процесс максимально автоматизирован, таск-трекер тесно связан с системой контроля версий, задачи проходят несколько стадий проверки. При этом сохранилась высокая скорость разработки: нормальной считается ситуация, когда задача появилась утром, а после обеда новый функционал уже доступен пользователям на сайте.

    Основные этапы


    Весь процесс можно разбить на этапы:
    1. Работа над продуктом: идея, подготовка ТЗ.
    2. Техническая реализация: декомпозиция, разработка.
    3. Тестирование и переводы на разные языки.
    4. Релиз для части пользователей.
    5. Релиз для всех.


    Как известно, любой процесс держится на людях, участвующих в нём. Давайте посчитаем, сколько человек участвует в типовом случае описанного выше процесса: менеджер продукта, дизайнер, копирайтер, менеджер проекта, разработчик, верстальщик, разработчик-ревьювер, QA-инженер. В этом списке не хватает одного действующего лица. Кого же мы намеренно не упомянули? Напишите свой вариант в комментариях!

    Девять человек — это минимальное количество участников процесса, когда мы разрабатываем новый функционал только на одном языке. Обычно это тестовый релиз для определённой группы пользователей или специальная промо-акция для конкретной страны. Когда мы делаем релиз для всех пользователей, в процесс включаются ещё и переводчики, которые осуществляют перевод на 40 языков. Некоторые языки поддерживаются в виде нескольких диалектов, например, американский английский и британский английский.

    Весь процесс контролируется и формализуется с помощью чётко проработанного workflow в таск-трекере (мы используем JIRA, www.atlassian.com/software/jira).

    Работа над продуктом


    Всё начинается с идеи. Обычно она появляется либо в рамках исследования «Как нам увеличить такой-то показатель», либо как улучшение существующего функционала. Разработку идеи доверяют определённому менеджеру продукта, например, отвечающему только за почтовые и push-уведомления, который оформляет её в виде задачи для своей команды со статусом «Идея».

    Накопившиеся идеи периодически просматриваются и начинается детальная проработка самых важных из них. В этот момент задача переводится в статус «Подготовка PRD», после чего менеджер продукта готовит краткое описание предполагаемого добавления и направляет его дизайнеру и копирайтеру. Точнее, на них переводится задача в таск-трекере, а все заинтересованные подписываются на её обновления, чтобы быть в курсе её текущего статуса.

    PRD (Product Requirements Document) — это нечто среднее между техническим заданием и достаточным описанием нового функционала. Обычно финальный вариант PRD даёт общее представление о том, как это будет выглядеть и как примерно должно работать. Все детали реализации уточняются в процессе разработки.

    Как только дизайн и тексты готовы, менеджер собирает все элементы (макеты, файлы с текстами) в PRD и завершает подробное описание нового сервиса. В результате, когда менеджер считает, что его задача становится максимально понятной и автономной, ей присваивается статус «Готова к разработке» и она передаётся менеджеру проекта из Features Team. Часто задачу не принимают с первого раза из-за неполного описания, большой технической сложности или других нюансов, которые обнаруживаются при её проверке менеджером проекта.

    Определение приоритета задачи и исполнителя


    Приоритет отправленных в разработку задач определяет главный менеджер из Product Team. При этом предпочтение отдаётся тем из них, которые являются составной частью крупных проектов по изменению тех или иных частей сайта. Важность же инфраструктурных задач (баги, исследования и т.п.) определяют сами разработчики.

    В свою очередь, разработчики на первое место ставят исправление критичных багов и минимизацию ошибок в логах — на каждую QA-отдел заводит новую задачу с высоким приоритетом. Более того, команда мониторинга круглосуточно следит за состоянием сайта и может связаться с разработчиком во внерабочее время, чтобы починить сломавшийся важный компонент.

    Созданием нового функционала занимается специальная команда PHP-программистов, которая разделена на группы по 2-4 человека. Каждая группа отвечает за свой набор компонентов. Так как задача обязательно привязывается к конкретному компоненту, группа, которая будет её выполнять, определяется автоматически.

    Все разработчики видят свои задачи на дашборде (англ. dashboard — страница с набором разных фильтров по задачам, настраивается специально под кажую группу) в таск-трекере, где они определённым образом сгруппированы и отсортированы. Есть пул задач на группу и есть список задач, к которым разработчик имеет непосредственное отношение (автор, исполнитель, ревьюер). Ситуация, когда человеку нечем заняться, невозможна в принципе. Ниже график поставленных и выполненных задач из таск-трекера за ноябрь, из которого видно, что работа реально кипит!



    Ниже — график задач, попавших в production. По нему можно оценить ежедневный объём исправлений и улучшений в Badoo:



    Техническая реализация


    С момента разработки и до выкладки на боевые сервера задачу, независимо от её сложности, полностью ведёт один PHP-программист. При необходимости он ставит подзадачу на другие компоненты коллегам из своего отдела, а также сотрудничает с другими специалистами (верстальщиками или системными программистами). Если задача нетривиальная и требует особых архитектурных решений, собирается рабочая группа из нескольких наиболее опытных разработчиков, которые сообща определяют, что и как будет сделано.

    Рассмотрим этот этап на примере создания фото-рейтинга (badoo.com/vote/), новая версия которого была недавно запущена. Из Product Team разработчикам поступил документ, содержащий следующие пункты:

    • общее описание, задачи проекта (к примеру, побудить пользователей загружать новые фото);
    • подробное описание нюансов ( как рассчитывается рейтинг фотографий, как подбираются следующие фотографии и т.п.);
    • макеты элементов интерфейса всех необходимых страниц и блоков с описанием того, что означает каждая кнопка, что должно происходить при нажатии по ссылкам, где и какие пункты меню должны быть добавлены;
    • описание того, как выглядит неавторизованная версия сервиса.


    На основании этого документа были поставлены задачи в разные отделы: верстка шаблонов, разработка сервисов на Си и инфраструктуры на сайте (элементы интерфейса, новые блоки, взаимодействие с сервисами и т.п.).

    Проверка каждой выполненной задачи достаточно формализована: есть определённый чек-лист и автоматизированный процесс. Каждая задача разрабатывается в своей ветке системы контроля версий (мы используем Git, git-scm.com). Ветки имеют особые правила именования (пример: BFG-123_another_cool_ticket), все коммиты автоматически получают номер задачи в начале описания (пример: [BFG-123]: great improvements on photo rating) — это помогает отслеживать движение кода от ветки разработчика до билда и итогового попадания в ветку master.

    При каждой отправке изменений из локальной копии в общий репозиторий срабатывают хуки, которые проверяют форматирование и оформление кода. Для форматирования кода под наши внутренние стандарты была создана специальная утилита phpcf, которая умеет как проверять, так и корректно форматировать код (вручную под стандарт обычно форматируют только те участки кода, которые, по мнению разработчика, логичнее переписать, чем оставить в виде громоздкой, но правильно форматированной конструкции).

    После того, как разработчик завершает разработку задачи, она попадает на код-ревью человеку, ответственному или имеющему хорошее представление о компоненте. Для осуществления ревью мы доработали утилиту gitphp (www.gitphp.org/) так, что в ней стало возможно просматривать общий diff ветки, оставлять комментарии к коду, которые впоследствии отправляются единым комментарием к задаче в JIRA. Обычно ревьюер проверяет, реализована ли задача в соответствии с правилами, принятыми в компании, нет ли явных оплошностей в виде оставленного дебага; может указать на целесообразность использования другого паттерна проектирования или предложить более оптимальную реализацию.

    В задаче обязательно должны присутствовать юнит-тесты на внесенные изменения, при этом существующие тесты не должны быть сломаны (!). После завершения на соответствующей ветке при помощи TeamCity (www.jetbrains.com/teamcity/) прогоняются все тесты, и если какие-то из них не проходят, разработчик получит уведомление об этом. Для ряда задач заранее настраивается мониторинг важных показателей. После проверки ревьюером задача попадает в отдел контроля качества.

    Тестирование и перевод


    Выполненная задача попадает в пул команды контроля качества и закрепляется за любым свободным тестировщиком. Обычно тут нет ответственных за компоненты, все тестируют всё, но при особо важных или срочных задачах разработчики могут договорится с отделом тестирования и передать задачу более опытному тестировщику по определённому направлению.

    Хорошей практикой считается составление разработчиком инструкции о том, как работает выполненная задача, что и как требуется протестировать. Best-practices по тестированию особо важных компонентов описываются в вики (всю подобную документацию мы ведем при помощи Confluence, www.atlassian.com/software/confluence).

    Во время тестирования все новые и изменённые слова и фразы из шаблонов попадают в специальную систему переводов (разработчик может заранее запустить этот процесс). Из неё при выкладке генерируются шаблоны для каждого из поддерживаемых языков.

    Для тестирования задач наша инфраструктура поддерживает несколько возможных окружений:

    • локальные домены на серверах разработки, которые эмулируют боевую инфраструктуру. Каждый разработчик ведёт работу на своём домене, а тестировщик проверяет задачи на своём;
    • индивидуальное тестовое боевое окружение: одновременно можно проверять неограниченное количество задач, независимо друг от друга;
    • общее тестовое боевое окружение, в которое попадает билд — набор задач, готовых к выкладке. В таком наборе задачи тестируются комплексно, чтобы одна не сломала другую.


    Когда задача получает статус «Протестировано», она автоматически попадёт в следующий билд (если нет незавершённых дочерних задач и готовы все переводы). Конечно же, конфликты решаются вручную — об этом приходит оповещение. Неработающие задачи откатываются и билд уезжает без них.

    Релиз


    После всех проверок задача вместе с билдом раскладывается на боевых серверах. Это происходит 2 раза в день (утром и вечером). Нередко новый функционал требуется протестировать на небольшой группе реальных пользователей, оценить эффективность и нагрузку, прежде чем включать для всего сайта. Обычно включение делается для нескольких стран или только для офиса разработки. Большинство задач разрабатываются сразу с возможностью частичного включения и быстрого отката.

    Но иногда после выкладки случается, что наше новшество не работает. Допустим, по-быстрому разложили непроверенный код или где-то была допущена логическая ошибка. Даже самые опытные разработчики порой допускают ошибки, которые приводят к неработоспособности некоторых частей системы, а порой она и вовсе складывается по принципу домино.

    На каждый из подобных инцидентов составляется «постмортем» — документ, в котором подробно расписаны причины проблемы, на что она повлияла, как быстро была исправлена и, самое важное, что было сделано, чтобы в дальнейшем такой проблемы не возникло. После этого постмортем выносится на общее обсуждение и каждый может высказаться и изложить свое видение ситуации.

    Для того, чтобы минимизировать подобные инциденты, мы стараемся максимально автоматизировать и улучшить наши процессы разработки, управление кодом, контроль над выкладками, а также средства мониторинга.

    Итог


    Результатом множества обсуждений, автоматизации, введения превентивных мер, постоянного аудита наших систем является то, что сейчас весь процесс разработки в Badoo понятен, эффективен и, что немаловажно, достаточно безопасен. Конечно, все возможные ошибки исключить невозможно, но я, как разработчик, чувствую себя комфортно и уверенно, когда вношу правки и разрабатываю новый код, зная, что он будет ещё неоднократно проверен. С одной стороны, это несколько расслабляет, но с другой — возможно, так и должен чувствовать себя программист, чтобы по-настоящему посвятить себя не просто разработке, а творческому процессу?

    Александр treg Трегер, разработчик.
    Андрей uni Сас, менеджер офлайн-уведомлений.
    Badoo 254,57
    Big Dating
    Поделиться публикацией
    Комментарии 80
    • +38
      Описание работы супер! А теперь пусть кто нибудь расскажет как все работает на самом деле.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +3
          Для feature-team (команды, которая занимается разработкой новой функциональности на сайте / доработкой старой) workflow соответствует тому, что написано в статье: вас не обманывают, всё действительно происходит именно так :).

          Помимо feature-team существуют другие отделы: биллинг, антиспам, «платформа», backoffice. Каждый из этих отделов имеет свою специфику при разработке, и многие этапы могут пропускаться, например этап code review в нашей «админке» не является столь критичным, как для основной функциональности на сайте.

          Я, к примеру, работаю в отделе «платформы», которая в основном занимается поддержанием и доработкой архитектуры сайта, а также выполняет массивный рефакторинг. Для наших задач workflow почти всегда отличается от описанного выше, поскольку те же задачи по рефакторингу нельзя деплоить, просто «замержив» задачу — нужно отдельное тестирование, аккуратная разработка и ручной контроль за происходящим на всех этапах работы.

          Так что да, статья описывает workflow, который относится к команде, которая разрабатывает новую функциональность и они действительно ему следуют :).
          • 0
            Каждый разработчик выкладывает свой кусочек в продакшен, или есть несколько ответственных за сервис, и только они катят что-то в продакшен?

            Как вообще процесс выкладки происходит? Вот есть новый билд (кстати, что это: набор php файлов, большой бинарь, пакет?), как он попадает на машины?
            • 0
              Каждая задача — ветка в гите. Билд — тоже ветка, куда мержатся задачи из всех веток, которые протестированы. Как только разработчик запушил ветку, и нажал «Готово» в таск-трекере, от него больше ничего не зависит. Как только тестировщики проверят задачу (читай — выгрузят к себе ветку и посмотрят, что все работает, и нажмет кнопку «Протестировано»), она автоматически будет смержена в ветку следующего билда и вместе с ним уедет на продакшен.
              • 0
                Как попадает на машины уже ответили чуть ниже, на эту тему был целый доклад addconf.ru/event.sdf/ru/add_3/authors/YuriyNasretdinov/786
              • +4
                youROCK, прошли те времена, когда «этап code review в нашей «админке» не являлся столь критичным, как для основной функциональности на сайте».
            • +2
              ммм… Подозреваю, что все делается очень и очень медленно. Это ж почти вотерфолл.
              • +3
                где ты тут ватерфол увидел, энтерпрайзник окаянный :)
                • +1
                  P.S. ничего не имею против энтерпрайза
                • 0
                  конструктивная критика? на каком этапе медленно?
                • +9
                  Летом плотно использовал продукт компании ) — классный, теперь доказали, что и разработка поставлена грамотно.
                  • 0
                    А как дела обстоят с client-side тестированием?
                    • 0
                      У нас тестировщики вручную всегда проверяют все задачи, прокликивают интерфейс, плюс активно пишутся селениум-тесты.
                      • +1
                        И формат кода не проверяется и автоматически не переформатируется, в отличии от PHP.
                        • 0
                          Артем, ты всех сдал.
                          Лучше расскажи про selenium. В какой момент пишутся тесты и на каком языке? Какой стек барузеров? Почему selenium, в конце концов? :]

                          P.S. А как собираете ошибки с клиента?
                          • 0
                            Это больше к тестировщикам вопрос. А что если не Selenium? Де факто стандарт. (Я не очень в теме, поэтому спрашиваю из любопытства.)

                            Стек браузеров с методикой примерно как у Яху, с оглядкой на собственную статистику. Проходят браузеры с долей больше 1%. IE7 попадает, хоть и в третьесортную категорию из-за отсталости. Планшеты тоже (iOS и Android), но на них традиционно меньше внимания обращается.
                            • +1
                              Я просто оставлю это здесь:
                              Goutte
                              Zombie
                              Sahi
                              • 0
                                Они лучше Селениума? Чем?
                                • 0
                                  Плюсы:
                                  * Запуск из консоли;
                                  * NodeJS;
                                  * API (+ DOM API, CSS Selectors);

                                  В идеале, можно запускать тесты и через Selenium, но это адова работа и пока её никто не сделал.
                                  • 0
                                    По-моему для тестировщиков это совсем не плюсы. Зачем нужен запуск из консоли, когда тесты должны работать автоматически? Вообще почему это плюс? Почему NodeJS плюс? API, по-моему, и в Селениуме есть.
                                    • 0
                                      Мы же говорим про автоматические тесты?

                                      Делаем хук на комит и запуск тесты, всё просто и быстро, с селениум такое не возможно. Да и кто работал с селениумом прекрасно знает, насколько там всё медленно, тест может занять часы.

                                      NodeJS записал в плюсы, т.к. с ним может работать и client-side разработчик.
                                      • 0
                                        Не уверен, что нужен хук на коммит. Потому что проверять логично билд, а, когда он собран, знает только релиз-инженер.
                              • 0
                                Но вы так и не ответили на вопрос «На каком языке и в какой момент пишутся тесты и кем?»
                                А так же, как мониторите ошибки на клиенте?
                        • +4
                          Позадаю немножко вопросов, если позволите ;-)

                          1. Сколько разработчиков, тестировщиков работают по этому процессу?
                          2. Сколько по времени занимает полный цикл подготовки релиза, с момента мерджа фич (раскладываете 2 раза в день, это я понял, а сколько билд маринуется на тестах)?
                          3. В релиз входят 1 модуль (подразумевается что весь фронт это 1 модуль) или может входить несколько (взаимозависимые изменения на фронте, в БД, бакенд серверах)?
                          4. Как/чем регресс и интеграционное тестирование делаете 2 раза в день?
                          5. Как/чем тестирование UI, особенно под несколькими браузерами?
                          6. Что делаете, если на этапе интеграционного тестирования находите ошибку (ведь за полдня ее можно не успеть пофиксить и перетестировать)?
                          • +1
                            1. Много, но не все (см. объяснения выше).
                            2. Зависит от задачи: от нескольких часов или даже минут (хотфикс) до многих месяцев (огромные или не шибко приоритетные задачи).
                            3. Как правило, несколько (если правильно понял вопрос).
                            4-5. Не буду врать, не в курсе (кроме наличия обычного тестирования, опять же см. выше).
                            6. Задача не проходит и доделывается. Если уже вышла, то заводятся баги и хотфиксы. Если всё вдруг сломалось, разумеется, есть возможность отката. (см. доклады Badoo, последний был Юрия youROCK Насретдинова).
                            • 0
                              1. Не могли бы вы сообщить приблизительное количество человек. Понятие «много» весьма растяжимо, тем более в сочетании с «но не все» ;-)
                              2. Не совсем понятно как билд (не таск) может мариноваться на тестах 2 месяца и при этом раскатываться 2 раза в день. как я понял из статьи, индивидуальные таски (которые разрабатывались долго и тестировались отдельно) интегрируются в билд. потом этот билд тестируется ( регресс + интеграция ). потом выкладывается. правильно ли я понимаю, что этап регрессионного тестирования и интеграционного занимает максимум полдня? или у вас есть какой то конвеер типа сегодня таски собрали в билд, тестируете день, потом выкладываете.
                              6. вариант «не проходит и доделывается», как я понял, возможен только если баги нашли на этапе тестирования отдельного таска. а если он уже собран в билд (бранч смерджен в мастер/staging, но еще билд не раскатан на прод), то есть была ошибка обнаружена на этапе интеграционного тестирования? все равно раскатываете и заводите баги и хотфиксы? или по дефолту откатываете коммит из гита? или ждете пока автор исправит?
                              • +1
                                1. Я бы сказал, десятки человек, точно сам не знаю. Даже сколько сотрудников не скажешь, число постоянно меняется.
                                2. Билд не может конечно, таски маринуются отдельно, и, когда уже ставится статус «готово к выкладыванию», попадаю в билд, который проверяется от силы несколько часов.
                                6. Не уверен, но, по-моему, либо быстро исправляется (те же хотфиксы), возможно, немного задерживая билд, либо изымается.
                                • +2
                                  Ветка билда на завтра создается сегодня, и сегодня же туда начинают домерживаться протестированные задачи до определенного часа. Если какая-то задача уже смерженная в билд не работает и быстрым фиксом никак не поправить, ее откатывают из билда (раньше git revert, сейчас как-то хитрее, т.к. реверт добавляет проблем впоследствии), либо просто собирают билд заного без этой задачи (создается ветка от мастера и туда заного мержатся задачи).

                                  Для патчей в билд у нас сделан специальный интерфейс, в который достаточно отправить diff правок, после чего они будут просмотрены и закомичены прямо в билд релиз-инженером.
                                  • 0
                                    6. зависит от важности задачи и сложности исправления бага. Можем подождать фикс, а можем и выкинуть задачу из деплоя.
                                    • +2
                                      6. Сейчас мы «вымерживаем» проблемные задачи из билда с помощью git rebase в полуавтоматическом режиме. При этом, мы тупо создаем новую ветку, в которой есть все коммиты, кроме указанного. Это одна из причин, почему создавать ветки прямо из билда у нас запрещено.
                                • 0
                                  Спасибо, очень интересно!
                                  Очень хочется услышать ответы на следующие вопросы:

                                  1. Чем не угодил phpcs? Почему используете свою утилиту?
                                  Кстати, насколько codestyle в Вашей компании отличается от PSR*?

                                  2. gitphp — гуй некрасивый и неудобный.
                                  Что, кроме исторического наследия или паранои, мешает использовать гитхаб или битбукет?
                                  И, кстати, Ваша компания существует уже не первый год, как так Вы перебрались на гит? Реквестирую статью!

                                  3. Очень интересен процесс автоматизации построения тегов(наверное) для деплоя.
                                  Это как раз очень хороший кейс, который ни в одной из известных мне компаний не автоматизирован.
                                  Получается надо запускать тесты после каждого коммита(нереально с большим кол-вом тестов), и если тесты прошли, подливать в тег билда.
                                  Раскройте плз подробнее этот процесс.

                                  4. Как происходит деплой? Капистрано-стайл? Его используете или что-то свое? Почему?
                                  • +4
                                    1. На сколько я знаю, phpcs умеет только указывать на ошибки в код-стайле, но не умеет сам их форматировать. Когда мы вводили четкий стандарт кодирования, обязательным условием было наличие утилиты, которая бы сама умела правильно форматировать код. Иначе это была бы ужасная пытка для разработчиков. Более того, наша утилита проверяет и форматирует только тот код, который был затронут в коммите.

                                    2. Он быстрый, простой и его не так сложно допиливать под свои нужды. Нам он нужен в первую очередь, чтобы смотреть дифф ветки и оставлять комментарии к строкам. Мы пробовали более тяжелые решения, например, FishEye но его так и не получилось по-нормальному внедрить, плюс он достаточно долго работал на нашем репозитории.

                                    В кратце, раньше у нас был svn, потом поставили git-svn, а потом по-командно перевелись на git. До сих пор у нас еще осталось несколько репозиториев на svn, которые по-тихоньку переводим на git.
                                    • +3
                                      про деплой у нас был доклад на одной из конференций: addconf.ru/event.sdf/ru/add_3/authors/YuriyNasretdinov/786
                                      • +3
                                        1. phpcs всем хорош, вот только форматировать не умеет, к сожалению. Думали о том, чтобы научить, но там нужно очень много переделывать. Мы думали (и думаем) о том, чтобы использовать и phpcf и phpcs вместе, ибо phpcf умеет проверять и исправлять пробельные символы + совсем простенькие преобразования.

                                        Наш код-стайл почти не отличается от PSR-1, есть совсем минорные отличия, связанные со спецификой и legacy именно нашего кода.

                                        2. no comments…

                                        3. У нас нет тегов для деплоя, используется просто ветка. При любых изменениях в этой ветке в teamcity прогоняются автотесты. При этом «стабильная» и production ветка — это всегда master

                                        4. Деплой был изначально сделан своими силами (в тот момент особо ничего интересного не было). Не так давно дорабатывался для использования UFTP для заливки файлов и нашей библиотечки libpssh для легкого и удобного коннекта по SSH к нашим сотням сервачков.
                                        • 0
                                          3. Смотрели и github, и gitlab, и прочие аналоги, они плохо ложатся на наш флоу разработки, для их нормального использования пришлось бы подгонять процесс под инструмент, что в корне неправильно. Общая закрытость и трудность допиливания под свои нужды также играет роль.
                                        • +1
                                          Для тех кому иллиюстрации показались скучными прилагаю видео
                                          www.youtube.com/watch?v=jWI_V_L_PkA
                                          • –3
                                            Причем здесь картинки ракет? Или вы сравниваете свой «производственный цикл» с таковым циклом в космической отрасли? Просто смешное сравнение. Крохотные команды разработчиков — просто ерунда по сравнению с производством ракеты. Посмотрел бы я, как у вас все бы было «гладко» в реально крупном проекте.
                                            • 0
                                              Хм… Вы точно уверены что баду маленький проект?
                                              • +4
                                                Немаленький. Но по сравнению с ракетно-космической отраслью — просто детский садик.
                                                • +3
                                                  Если так рассуждать, то даже Гугл окажется дестким садиком. Богатым таким садиком.
                                                  • 0
                                                    в чем-то вы правы.
                                                • +2
                                                  Я думаю, картинками ракет автор хотел создать аллюзию на «Rocket science»: anything overly complex, detailed or confusing (http://en.wiktionary.org/wiki/rocket_science)
                                                • 0
                                                  Менеджер команды не становится уским звеном? Как часто задачи возвращают на доработку требований?
                                                  С моего опыта наличие нескольких Product manager (или product owner в гибких методологиях) и команд которые формируются под задачу очень эфективный процес. Они помогают перевости требования с «птичего языка» и нечётких требований аля «кнопка „сделать круто“» в требования понятные команде разработчиков с минимальным отвлечением сотрудников заинтересованых отделов. У вашей модели заложено потенциальное бутылочное горлышко в виде менеджера который распределяет работу, а также проблема слиском большого количества заинтересованых лиц. Когда нет авторитетного лица которое «над схваткой» и его решение «в последней инстанции» очень сложно удержатся от постоянного разрастания требований к разработываемым фичам.
                                                  Насчёт git, какие недостатки не дали исспользовать GitHub for Enterprise или Attlasian Crucible если хочется большей формализации, потому что code review наверное не та ключевая деятельность которой стоит заниматся, если вы не разработчик систем code review?
                                                  • +3
                                                    Менеджер проектов, как у нас любят говорить, работает в основном со списками и осуществляет первичную приемку задач. Дальше уже задачу целиком ведет разработчик, а менеджер следит за ее статусом и сроками. Зачастую задачу сразу можно отнести к тому или иному компоненту, поэтому она достаточно быстро минует менеджера проектов и попадает в пул задач соответствующей группы разработчиков. Когда разработчик берет задачу, если там что-то не понятно, то он сам все уточняет у продуктового менеджера. Отсюда бутылочного горлышка в виде менеджера не создается, но возрастает ответственность разработчика, которому приходится самостоятельно переводить с «птичьего». Конечно, при необходимости менеджер разруливает спорные вопросы и разрастания требований. К примеру, если product team очень хочет внести какие-то существенные изменения, мы можем запланировать вторую итерацию для этого проекта.
                                                    • 0
                                                      Fisheye и Crucible с огромным скрипом работают с большими и частообновляемыми git -репозиториями. По нашему опыту задержка с индексацией пришедших изменений может легко достигать 1-2 часов, что делает невозможным быстрый code-review только что сделанного тикета.
                                                      Общение с атлассианавцами в попытках решить эти проблемы ни к чему ни привело.
                                                      Было бы интересно узнать про опыт работы с этими инструментами в других крупных проектах.
                                                      Про GitHub for Enterprise описал выше.

                                                      Решение на базе gitphp, которое было сделано за пару недель и теперь активно развивается и допиливается именно под наши нужды, работает быстро и четко. Тем более что заинтегрировать его с JIRA через стандартный API не представляет никаких проблем.
                                                    • +4
                                                      Такое ощущение, что коментаторы в основном пытаются придраться к чему-нибудь из зависти. Да, ребята, так работают в солидных ИТ компаниях.
                                                      • –2
                                                        В солидных ИТ компаниях работают по-разному. Выше нарисован процесс вертикально-интегрированной разработки, который известен своей корявостью во множестве организаций. Вот люди и удивляются, как это может эффективно работать.
                                                        • +2
                                                          Извините, не знаю, такой термин, как вертикально-интегрированный процесс. По мне так процесс, как процесс. Вполне гибкий. А констуктивных замечаний тут что то не пишут.
                                                          • 0
                                                            А что вы подразумеваете под эффективностью и каковы критерии эффективности для компании, число сотрудников которой исчисляется сотнями?
                                                        • +1
                                                          Очень интересно! Спасибо за такой подробный рассказ. Не могли бы вы также ответить на пару вопросов?
                                                          1. Какие фишки Jira'ы вы используете? Например, версионирование и билды, интеграция с CVS, интеграция с Confluence, интеграция с FishEye,…
                                                          2. Как вы используете Confluence — постятся ли там релиз ноутсы, what's new, какие-нибудь known issues и т.д?
                                                          3. Используете ли вы CI с запуском тестов на нем?
                                                          • 0
                                                            И еще немного:
                                                            4. Как у вас ведется девелоперская документация, типа функциональной спецификации, требований к функционалу, описания архитектуры и т.д.? Как вы ее храните, когда и чьими силами обновляете?
                                                            5. Участвуют ли QA в подготовке функциональных и юнит-тестов, их валидации?
                                                            • +1
                                                              1. API
                                                              3. TeamCity
                                                              5. Участвуют

                                                              Возможно в ближайшее время кто-то раскроет некоторые из деталей непрерывной интеграции здесь или на одной из конференций.
                                                              • 0
                                                                Круто, спасибо! А про API можно немного подробнее? Что вы с ним делаете — получаете какие-то данные (отчетность, например), либо отправляете POST-запросы (например, для автоматического создания тикетов)?
                                                                • +1
                                                                  Например… TeamCity пишет в JIRA о пройденных тестах.
                                                                  В настоящий момент больше можно узнать из предыдущей статьи — AIDA. Автоматизация работы с Git, JIRA и TeamCity.
                                                                  • 0
                                                                    1. Вот так ещё например
                                                                    Для осуществления ревью мы доработали утилиту gitphp (www.gitphp.org/) так, что в ней стало возможно просматривать общий diff ветки, оставлять комментарии к коду, которые впоследствии отправляются единым комментарием к задаче в JIRA
                                                              • 0
                                                                2. В Confluence у нас хранится документация и подготавливаются PRD по функционалу со стороны Product Team. Описания обновлений у нас рассылаются в maillist при каждом деплое, обновлении версий мобильных приложений и раз в неделю рассылается сводка по всем отделам.
                                                              • 0
                                                                А как у вас происходит обновление схемы в базе?
                                                                • +1
                                                                  Простые и быстрые правки делают разработчики самостоятельно. Если надо обновить сотню баз, такие альтеры осуществляет отдел системного администрирования в низах трафика. Самое частое обновление схемы — это добавление новых полей, поэтому никаких проблем не возникает.

                                                                  Если нужно изменить существующие поля:
                                                                  1. пишут код совместимый со старой и новой схемой работы, релизят его
                                                                  2. вносят правки в базы
                                                                  3. оставляют код, работающий по новой схеме
                                                                  • 0
                                                                    То есть скрипты миграции не пишутся и все прямо руками? Или вы просто имеете в виду, что скрипты запускаются самим разработчиком?
                                                                    • +1
                                                                      Специфика такая, что править базу приходится достаточно редко, поэтому у нас нет большой необходимости в скриптах миграции. Небольшие изменения вносятся руками прямо в консоли mysql. Когда надо очень много таблиц обновить (к примеру таблицы, по которым шардятся пользователи, их тысячи), то тут конечно системный администратор запускает скрипт, который обходит базы и выполняет sql запрос.
                                                                    • 0
                                                                      Для добавления нового поля вы отключаете по одному серверу БД, накатываете изменения и включаете? А потом когда на все сервера накатились изменения выкладываете код, которому нужны эти поля, так?
                                                                      • 0
                                                                        Нет, мы ничего не отключаем (возможно только для обновления ПО). Просто подбирается время, когда низкий трафик, чтобы не создавать проблем пользователям и выполняется альтер. Когда на все сервера накатились изменения, то да, мы выкладываем код, который их использует.
                                                                        • 0
                                                                          Логично, т.е. получается когда накатывается альтер, то запросы ждут пока снимется блокировка с таблицы. Процент timeout`ов будет крайне низкий из-за маленького трафика.
                                                                          • +1
                                                                            Тут ещё интересный момент, что «низ трафика» это всё равно порядочная нагрузка, поэтому без дополнительных действий оно работать скорее всего не будет. У нас в добавок к этому используется очень «мелкий» шардинг: на каждом сервере по несколько схем, в каждой схеме порядка 5000 таблиц, примерно по одной на 1000 пользователей. Это позволяет избежать длительных блокировок при запросах, даже если сам альтер «тяжелый».
                                                                            • 0
                                                                              А схемы используются используются для какой цели? Партицирование?
                                                                              • 0
                                                                                Это все, в основном, шардинг пользовательских данных — есть X серверов баз данных, на каждом крутится Y схем, в каждой из которых Z таблиц по N пользователей в каждой.
                                                                          • 0
                                                                            Неужели у вас бывает низкий трафик? :)
                                                                            А действительно, вы же работаете по всему миру, и из-за часовых поясов активность в течение дня должна быть примерно одинакова. Или это не так?
                                                                            • 0
                                                                              нагрузка по миру распределяется неравномерно.
                                                                              • 0
                                                                                У нас 2 дата-центра — один в Америке, другой в Европе, и данные пользователей по ним распределены соответствующим образом. Поэтому в каждом из них в определенное время нагрузка все таки падает.
                                                                      • 0
                                                                        Почему TeamCity, а не atlassian's bamboo?
                                                                        • 0
                                                                          У меня вопрос — действительно ли полное ТЗ по задаче у вас формируется примерно так:

                                                                          Рисуется, верстается, менеджер проекта или направления сам или с помощью тех. писателя пишет полное исчерпывающее ТЗ.
                                                                          Все вопросы от программистов решаются в рамках комментариев в задаче — т.е. разработчик спрашивает, ему там отвечают и ничего не остается не задокументированным?
                                                                          • +1
                                                                            Полного ТЗ у нас не бывает, есть именно продуктовый документ, в комментариях к которому действительно много чего может обсуждаться. Если в процессе разработки мне что-то не понятно, я могу позвонить менеджеру и уточнить вопрос, а в комментарии к тикету дописать «договорились с менеджером, что полоски будут синего цвета», чтобы избежать вопросов от тестировщиков.

                                                                            Как функционал работает с технической точки зрения, этот документ может описывать, но очень поверхностно. Обычно мы пишем такую документацию постфактум на особо сложные участки системы.
                                                                          • 0
                                                                            Александр, вы описали процесс работы одной команды над одной фичей. Интересно, как строится процесс, когда фича требует какого-то функионала на фронте, функционала в админке и, допустим, каких-либо изменений в биллинге, то есть поучаствовать в фиче (или проекте) должны три команды разработки, при этом релиз их частей должен быть синхронизирован по времени.

                                                                            Получается, что в процессе участвут менеджер продукта, который «сгенерил идею» и подготовил PRD, и три менеджера проектов по одному из каждой команды разработки? Как строится дальнейший процесс? Кто им управляет и как синхронизирует между собой разные команды разработки для того, чтобы весь проект попал в продакшен в срок и в полном объеме (все три части)?
                                                                            • 0
                                                                              Всю задачу от начала и до конца ведет один php-программист. Допустим, мне пришла задача, в ней PRD с макетами. Я сразу ставлю задачу в пул команды Frontend, ссылаясь на родительскую задачу. Если нужен биллинг, к примеру, это промо акция и при переходе по ссылке мне надо начислить 100 кредитов, я договариваюсь с человеком из биллинга, который отвечает за промо-акции и ставлю на него подзадачу. Если я не знаю, кто среди них может мне помочь, тогда я обращаюсь к менеджеру.

                                                                              Когда я ставлю задачу на верстку макетов и на заведение новой промо-акции, я всем говорю одну ветку в git, в которой необходимо вести разработку. То есть синхронизировать ничего не надо, я лишь дожидаюсь пока будут сделаны подзадачи, параллельно подготавливая свою часть. Далее я свожу все вместе, проверяю и отправляю на тестирование.
                                                                            • 0
                                                                              И еще, если возможно, расскажите чуть подробнее про то, что включает в себя «идеальный» PRD.
                                                                              • +1
                                                                                У вас в списке городов в Таиланде нет Паттайи. Это странно. Пытался дать знать поддержке сайта, но никаких контактов тоже не нашел.
                                                                                • +1
                                                                                  Спасибо, скоро (скорее всего завтра) появится
                                                                                • 0
                                                                                  А что такое «Features team» и кто такие «менеджеры проекта» из этого «Features team»?

                                                                                  И еще такой вопрос. Помимо веб-клиента есть еще мобильные приложения. На этапе проектирования продумывается реализация фичи сразу везде (сайт, мобильные клиенты)? На этапе разработки — новые фичи запиливаются одновременно во всех клиентах? Или сначала фича может быть поддержана и зарелизена только на сайте, а когда-то потом — в iOS- и Android-приложениях?
                                                                                  • 0
                                                                                    Ребят, вы не упомянули главное действующее лицо в процессе. Это пользователь.

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое