Процесс Code Review с Atlassian Stash

Всем привет! Вот и наша компания решила завести блог на Хабре (в конце концов, не вечно же читать чужие статьи). В профиле компании вы можете посмотреть, чем мы занимаемся. В ближайшее время мы предложим вашему вниманию цикл статей по широкому спектру тем: от сервисов дистрибуции и поддержки тестовых сборок iOS приложений до программного управления IIS. А первая наша публикация посвящена Atlassian Stash.

На текущий день на хабре практически отсутствует какая бы то ни было информация об Atlassian Stash (всего один анонс и одна статья на тему установки). Хотя инструмент, на самом деле, прекрасный, и определенно стоящий рассмотрения в случае использования всего стэка Atlassian. Я хочу рассказать что это такое и как эту штуку можно добавить в процесс разработки.

Небольшая предыстория — у нас появился новый заказчик и возможность построить инфраструктуру для разработки практически с нуля. Сразу захотелось сделать «всё правильно» — git/CI/code-review и т.д. Все вроде как согласны, что code-review это важно и нужно, меж тем далеко не все его используют, а если используют, то в основном некую постфактум версию — закоммитил в транк, кто-то позже посмотрел. Где-то по workflow запрещено резолвить задачу, пока кто-нибудь не посмотрел код коммита, ну или другие устно/письменно-оговорённые ограничения. Нам же хотелось сделать процесс более контролируемым с технической точки зрения.

Из решений для / с поддержкой code-review на ум пришли: TFS, Atlassian Stash, Github, Gerrit, новенький Upsource от JetBrains.

Вкратце по каждому:

1. У нас не только .NET и Windows, поэтому TFS отпадает (да и в любом случае, ревью там не работает в случае использования git).
2. Github — все понятно, дает приватные репозитории или standalone версию Github Enterprise. Пример pull-request'а и ревью — github.com/jquery/jquery/pull/1241/files. Главный аргумент против — приватным репозиториям приватный же хостинг.
3. Gerrit — сделан специально для code review, все круто, но нам бы еще сами репозитории хостить где-нибудь. Кроме того, использование может быть несколько сложным для людей, которые привыкли к SVN.
4. Upsource — та же претензия что и к Gerrit — инструмент исключительно для Code-Review, не для управления репозиториями. Да и не существовало его ещё на момент выбора.
5. Stash — относительно новый продукт от Atlassian. Этакий github в миниатюре — хостит/менеджит репозитории, интегрируется с Jira/Bamboo, дает делать пул-реквесты, форки, а главное — не в облаке. Вообще говоря, у них есть ещё и Crucible (ex-Fisheye), но он несколько устаревший и сам по себе репозиториями не управляет.

В итоге, решили остановиться на Stash'е. Установка/настройка/интеграция типична для всех Atlassian'овских продуктов, останавливаться на ней смысла особо нет. Поддерживается исключительно git, а требование code-review реализуется через пул-реквесты, причём возможно настраивать количество минимальных апрувов/успешных билдов, чтобы можно было смержить реквест. Билды нужны в случае интеграции с Bamboo — например, чтобы гарантировать, что в этом бранче никто не сломал юнит-тесты. Видимо, количество успешных билдов имеет смысл только в случае наличия отдельно запускаемых performance (или других, занимающих относительно долгое время и потому не выполняющихся на каждый коммит) тестов в отдельном билде. Ну, я не придумал другого применения.

Gitflow

Как правильно организовать ветки, чтобы потом не было мучительно больно, уже давно придумано до нас, поэтому на самом workflow останавливаться не буду — просто напишу примерный алгоритм:

1. Все фичи/багфиксы должны быть в отдельных бранчах. Ну, тут всё просто — Stash менеджит git репозитории сам, ветки, разумеется, поддерживаются, причем ветки можно создавать прямо из окна issue в Jira.
2. Разработчик пушит код в этот бранч.
3. Если в Bamboo есть настроенный билд, который автоматически подхватывает новые бранчи, Stash узнает о том, что билд собрался.
4. Девелопер создает PR и назначает ревьюверов. Назначает руками, случайным образом из списка, увы, нельзя.
5. Ревьювер получает нотификацию по почте, смотрит изменения (стандартный diff либо двухпанельное сравнение), может оставлять комментарии и так далее. У нас на практике получается так, что в ревьюверы ставится чуть ли не вся команда, а на кнопку Approve нажимают люди, чей код коснулись правки, либо наиболее знакомые с затронутой частью проекта.
6. Разработчик дожидается аппрува и, при наличии зеленого билда, может смержить pull-request и зарезолвить задачу.

Видео от Atlassian с демонстрацией данного процесса:

Там показано как всё круто интегрируется, но кое-что из всего этого (например, кнопка Start Review) у нас не заработало. Возможно, проблема с версией.

Напоследок небольшая выжимка полезных фич / ответов на возможные вопросы

• Поддерживаемые протоколы: HTTP/HTTPS и SSH. В первом случае аутентификация по паролю, во втором — по ключу.
• Подсветка синтаксиса.
• Возможность сравнивать бранчи без создания pull-request'ов.
• Email-нотификации, разумеется. О новых pull-request'ах, новых комментариях к созданным pull-request'ам и т.д.
• Существует платный плагин Notifyr, который позволяет отметить репозиторий как избранный и получать нотификации еще и обо всех пушах в него.
• Поддерживает личные пользовательские репозитории, правами на которые управляет сам пользователь.
• Можно делать форки. Автосинхронизация веток тоже поддерживается. Ложка дегтя — если хотим использовать модель разработки, где все работают в своих форках, а потом делают pull-request в основной репозиторий, то не получится добавить зависимость на «зелёные» билды в Bamboo — он просто не знает о существовании форков.
• В 3.x версии появились лайки у комментариев. Лично мое мнение, что хоть какое-то практическое значение они имеют в случае open-source (очень большой и распределённойкоманды).
• Нельзя запретить (по крайней мере, в версии 2.x, уже есть 3.x) прямые коммиты (без pull-request'ов) в какой-либо бранч. На деле прямой merge веток, скажем, в develop в обход Stash'а все-равно приходится запрещать на словах, поскольку merge это фича git'а. Можно, конечно, дать права на ветку только одному ответственному за merge пользователю, но это имеет смысл только в крайне редких случаях.
• Можно писать хуки на Java и добавлять их как плагины (например, если нужно решить проблему из предыдущего пункта).
• Можно использовать Jira/Crowd сервер в качестве User Directory. Каждому юзеру в отдельности можно снять галку Stash User — это может пригодится в том случае, если у вас в Jira много пользователей, а лицензия на Stash поддерживает, скажем, только 50 пользователей.
• Достаточно прожорлив в плане потребления памяти.
• Несмотря на то, что и Stash, и Bitbucket продукты одной и той же компании, code-base у них разный, поэтому наличие какой-либо фичи у одного из них не означает наличие такой же в другом.