Процес 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 у них різний, тому наявність якої-небудь фічі в одного з них не означає наявність такої ж в іншому.

Що у Вас використовується для хостингу репозиторіїв / code review?

/>
/>


<input type=«radio» id=«vv64639»
class=«radio js-field-data»
name=«variant[]»
value=«64639» />
Stash
<input type=«radio» id=«vv64641»
class=«radio js-field-data»
name=«variant[]»
value=«64641» />
Github (з рідним або стороннім code review движком)
<input type=«radio» id=«vv64643»
class=«radio js-field-data»
name=«variant[]»
value=«64643» />
Bitbucket
<input type=«radio» id=«vv64645»
class=«radio js-field-data»
name=«variant[]»
value=«64645» />
Інше рішення з використанням Gerrit
<input type=«radio» id=«vv64647»
class=«radio js-field-data»
name=«variant[]»
value=«64647» />
Інше (в коментарях)
<input type=«radio» id=«vv64649»
class=«radio js-field-data»
name=«variant[]»
value=«64649» />
Не використовуємо git / хочу побачити результати

Проголосувало 20 осіб. Утрималося-2 людини.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.