2 июня 2014 в 11:27

Почему мы для code review выбрали Bitbucket, а не GitHub



В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.

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

Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.


1. Unlimited private repos


Тарифные планы GitHub основываются на количестве приватных репозитериев. Тарифные планы Bitbucket — на количестве разработчиков в команде. Т.е. GitHub больше подходит для больших команд с малым количеством проектов, а Bitbucket — малым и средним командам с большим количеством проектов. Мы как раз являемся вторым вариантом и платим 10$ в месяц вместо 100$ в случае использования GitHub.

2. Side-by-side diff


После Gerrit side-by-side diff является необходимым условием, Bitbucket им обладает:
image
Здесь есть несколько некритичных недостатков, таких как невозможность комментирования кода в модальном окне side-by-side diff (issue).

3. Запрет push-а в master ветку (issue)


Каждый pull request в нашей компании должен пройти code review (CR). Поэтому достаточно важным в нашем случае является подстраховка от случайного push в master ветку. Т.е. рабочий процесс выглядит так:
  1. разработчик создает ветку (feature/foo или bug/bar)
  2. делает изменения в коде и push в созданную ветку
  3. делает pull request в случае если по его мнению ветка готова для CR
  4. происходит CR, который хорошо описан в bitbucket guideline
  5. reviewer жмет кнопку Approve в случае если код по его мнению прошел CR
  6. автор pull request-a делает merge после того как получил Approve как минимум от двух человек


4. В ногу со временем


На днях Bitbucket выкатили новый резиновый интерфейс. Конечно, есть недочеты, но хорошая тенденция очевидна.

5. Приятные мелочи


  • кнопка Approved для pull request-а
  • нет жесткого ограничения размера репозитория/файла
  • русский язык интерфейса (мы им не пользуемся, но все же)


Две детали, которые пришлось временно решить userscript-ами:
  1. fancybox. К сожалению да, ребята из команды Bitbucket используют fancybox в самом неподходящем для этого месте — Side-by-side diff. Скрипт выключает раздражающую fade-out анимацию
  2. подсветка пробелов/табов, чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода
@limonte
карма
89,7
рейтинг 0,0
Full-Stack PHP/JS developer
Похожие публикации
Самое читаемое Разработка

Комментарии (65)

  • 0
    Если первый пункт не критичен, лучше выбрать Stash (тоже от Atlassian). Оно того стоит.
    • +3
      Stash дорого. $1800 на 11 человек.
      • +3
        $1800 это на 25 человек. А на 10 — всего $10.
        • +8
          Для минусующих объясняю:
          ТС платит $10 в месяц за Bitbucket. Это тариф для 10 участников.
          Stash для этого же количества мемберов — так же $10. И внимание — One-time payment. Не ежемесячно.
          Но да, если нужно будет на одного участника больше — резкий рывок к $1800.
          • +1
            Stash «опасен» тем, что за год количество участников может превысить 10 (а если есть группа, то сама группа тоже считается как участник) и потом придётся раскошелиться до $1800
          • +2
            Вы не пробовали ПРОДЛИТЬ продукты Atlassian, купленные за 10$? Вас ждет неприятный сюрприз. Или — отсутствие обновлений.
            • 0
              Справедливости ради надо отменить, что при желании можно купить все заново по 10$ на другую карточку, установить все на чистые базы, и путем замены Server-ID в существующих БД/конфигах на новый (для каждого из продуктов) получить еще год почти-бесплатных обновлений
            • +4
              Не могли бы, пожалуйста, поделиться сакральным знанием какие сюрпризы ожидают тех, кто захочет продлить лицензию?
              На сайте у них вроде бы как английским по белому написано что это можно сделать за те же 10$
              • 0
                Прошу прощения за дезинформацию, оказывается лицензии на 10 пользователей у FisheEye бывают как Starter, так и вполне обычными, Commercial. При этом стоимость продления последних больше в 40 раз.
            • 0
              Crowd starter обновляется нормально (в смысле, renew), за те же $10.
    • 0
      Мне только что Stash сказать что появился side-by-side diff, и предложил воспользоваться
  • +1
    Реально всё сводится к 1му моменту :)

    2й решается плагинами/скриптами готовыми: chrome.google.com/webstore/detail/side-by-side-diff-view-in/ihmhmdmhllhleioijdeoocgoddjckbcd

    3й имеет штатное решение хуком

    «кнопка Approved для pull request-а» — у гитхаба автоматический мерж есть для PR
    размер в сотни метров на файл — как правило за глаза и за уши

    а рус и интерфейс это вещи субьективные и с ними всегда можно жить.

    хотя как по мне, то для приватных репозиториев лучше приватный же сервер.
    • +3
      Пробовал это расширение, не работает оно так как нужно. К сожалению не помню, что именно нас не устроило. К тому же

      image

      Не самая лучшая идея заменять необходимый функционал сторонними расширениями, вы так не считаете?
      • +1
        ну github.com/KuiKui/Octosplit — исходники есть и публичны :)

        Кстати, помнится в gitweb включается sbs-diff легко: gist.github.com/scharan/1274726
        и тогда вообще всё получается бесплатно, приватно и секурно.

        а еще есть консольное cdiff, кою можно вызывать git difftool; есть meld;
        есть еще TortoiseGIT который как раз няшно и гуёво показывает именно как надо.
        • +8
          А ещё есть нормальные IDE, например от
          реклама
          Jetbrains
          , где side-by-side diff встроен.
          • +1
            Которая стоит денег ;)
            • +31
              Которая стоит своих денег ;)
              • +4
                Bitbucket также стоит своих денег. Не понимаю логику.
            • 0
              Строго говоря, не обязательно — есть же и Community Edition, и Ultimate Edition с Open Source License. Но в большинстве случаев (т.е. если проекты с закрытыми исходниками и в областях, не покрываемых Community Edition) — да, стоит денег.
          • +1
            Согласен. Но функциональность веб-diff'а c возможностью комментирования это одно, а просмотр diff'а в IDE — другое. В IDE ведь коммент коллеге не напишешь :)
            • +1
              Ну, для таких случаев мы обычно копируем ссылку (в вышеупомянутом IDE — copy reference) вида /project/file.ext:line-number и пользуемся общим чатом. Однако, конечно, когда речь о большом кол-ве комментариев удобнее комментировать в вебе.

              P.S. эта же ссылка элементарно вставляется на машине разработчика и тот моментально попадает на нужную строку у себя и исправляет что нужно. В некотором случае это удобнее чем смотреть комментарии в вебе и потом всё-равно возвращаться к тому же месту в своём коде.
              • 0
                Кстати, для того же IDE был даже где-то плагин IDE-jabber. Хоть он был весьма уныл, но идея хорошая.
            • 0
              Совершенно не разбираюсь в теме, но вроде в последней Visual Studio можно оставлять комментарии:)
            • 0
              Дык ТС говорит, что и в bitbucket не напишешь.
              • +1
                Напишешь. Нельзя написать в режиме Side-by-Side, однако в обычном режиме (как на GitHub) всё пишется как обычно.
            • +2
              точности ради, есть IDE Talk
          • +2
            Это есть и в EGit для Eclipse. И вовсе без денег :)
            • 0
              Вот только он с символьными ссылками не умеет работать. Постоянно предлагает добавить в индекс файлы из ссылки на директорию.
          • 0
            Очень люблю продукты от JetBrains, однако diff у них не очень хороший.
            • 0
              У них отличная ТП, если у вас есть конкретные предложения по улучшению — youtrack.jetbrains.com/dashboard#newissue=yes
              • 0
                Я отписывал им о найденных багах, но видимо отсутствие голосов делает свое дело.
                • 0
                  У меня прямо противоположная история — все те немногие баги (именно баги, а не пожелания по улучшению), которые у меня получалось найти, исправлялись _очень_ быстро (десятки минут и единицы часов). Но это если говорить о самой IDE, с плагинами ситуация похуже, а часто и заметно хуже.
    • +3
      3й имеет штатное решение хуком
      локальным штоле? это, конечно, немного лучше чем «не делайте так, иначе сломаю ногу», но не сильно.
    • 0
      3й имеет штатное решение хуком

      github же не поддерживает before push хуки?
      • 0
        нет, но речь ведь идёт о своём сервере :)
  • 0
    чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода

    То есть code review у вас есть, а CI сервер с проверкой code style у вас нет? Не цените вы свое время
    • +1
      Вы не учитываете, что у нас не только PHP. Jenkins конечно же работает :)
      • 0
        Да, исправил комментарий. Увидел питон в скринах — pychecker.sourceforge.net/ вот что показывают первые ссылки в гугле.
        Да и проверить пробелы/табы можно регулярками, если с используемым языком плохо. Но заставлять это делать ревьювера, даже с плагином — мне кажется странно.
        • 0
          Именно для того, чтобы тыканьем в табы не занимался reviewer и был написан вышеуказанный userscript.
          Автор коммита ДО pull request видит их и исправляет.
          • 0
            Ну CI можно настроить и на форки разработчиков, если это нужно.
    • 0
      Как показывает практика, лучше все же не пропустить плохой код на уровне pull request, чем получить всем начальством на email сообщение от CI о том, что билд сфейлился.

      P.S. не факт, что это очень актуально для многих проектов. Но поверьте, учавствуя в разработке такого крупного проекта, как oDesk.com я понял, как полезны pull request'ы. В паре с CI.
      • 0
        А что плохого в фейле билда внутри ветки для фичи/правки бага?
        • 0
          Я говорю о мастере.
          чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода

          Думаю вероятность того, что такой фейл билда внутри ветки для фичи может быть незамечен/проигнорирован все же больше, чем того, что его не заметят при код ревью и аппруве пул реквеста.
          • +1
            Вы с CI работали? Посмотрите любой открытый проект, например github.com/composer/composer/pull/2819
            CI сервер проверяет CS, если нужно, прогоняет тесты, учитывя изменения в ветке и результат мержа виден уже внутри PR
            • 0
              Работал и работаю. Вы меня не правильно поняли.
  • 0
    А на битбакете до сих пор при обновлении бранча нужно обновлять пул-реквест?
    • +3
      Нет, pull request обновляется автоматически.
  • +4
    По поводу третьего пункта: если каждый разработчик будет иметь свой форк проекта на гитхабе, и делать пул-реквест не из одной ветки origin repo в другую, а из своей ветки в своем репозитории в мастер основного репозитория, то тогда проблемы с доступами легко решаются средствами гитхаба. Плюс это дает больше понимания, над чем трудится каждый человек. Давать всем разработчикам полный доступ на создание веток в основном репозитории не всегда полезно и может привести к бардаку.
  • 0
    А еще CodeReview есть у бесплатного Phabricator.
    • +4
      Посидел я на оупенсорс тулзах типа redmine, phabricator, gitlab и что-то пришел к выводу, что продукты Atlassian стоят-таки своих денег. Для небольших команд есть недорогая линейка OnDemand, для больших, как мне кажется, цена обычной лицензии не так уж должна быть велика.
  • +3
    А почему не Gitlab на каком-нибудь VPS сервере за $5/мес? Если репозитории частные, то может лучше и частный сервер завести?
    • 0
      Поддерживаю. У нас Gitlab развёрнут в нашей серверной, проблем не ощущаем. Кое-где для интеграции с внутренними процессами допилили код, он там весьма вменяемый. Side-by-side diff там есть :-)
      • 0
        Есть, но без синхронного горизонтального скролла, неудобно.
  • 0
    > подсветка пробелов/табов, чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода

    Можно повесить Code Sniffer на хук коммита в репозиторий и проблемы с правилами форматирования кода будут решены. Code Sniffer не пропустит коммиты не по стандарту.
  • +3
    Неужели amend commit — это какая-то сложная концепция? Это вообще была первая фича, которой я дико порадовался при переходе на git с cvs. Просто, элегантно и нужно.
  • +6
    3/4 комментов объясняют вам, почему решение, которое вас устраивает, является неверным. :)
    • +3
      потому, что диалог получается только при несогласиях. иначе разговоры были бы
      > А я сделал А!
      >> о! круто! молодцы
      >>> да! мы молодцы!
      >>>> вы молодцы, что понимаете что молодцы!
      >>>>> согласен!
      >>>>>> совершенно согласен!
      >>>>>>> это не могло быть иначе!
      >>>>>>>> вы снова абсолютно правы!
  • 0
    git — локальная VCS, попытка сделать из него веб-редактор кода — возврат к SVN.
    • 0
      не знаю, мне понравилось делать мелкие правки прямо из вебморды гитхаба
    • +1
      BA и QA часто проще в вебе просто подредактировать файл, чем учиться работать с GIT. Особенно BA или копирайтерам.
      • 0
        согласен, читал недавно djbook.ru и нашел ошибку в переводе, сделал пулреквест прямо из браузера, если бы мне пришлось клонить репозиторий сначала, я бы не стал заморачиваться с этим.
  • +1
    github недавно ввёл side-by-side diff
    • 0
      Да слышал, вчера анонсировали. Их side-by-side diff куда более юзабельнее, чем на Bitbucket.

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