Здравствуйте, netch80, Вы писали:

В основном возразить нечего, процесс разработки — это всё-таки вопрос предпочтений, так что отвечу на вопросы — и давайте закругляться

S>>2. Если человек в коммит кидает откровенную ересь, которая не соответствует описанию задачи в тикете — тикет просто возвращается ему на доработку.
N>Простите, возвращается *тикет* или *коммит*?
Конечно же тикет, коммит уже сделан. Выпилить уже сделанный коммит или полноценно проверить код до коммита — не вариант, согласитесь.

S>> Если количество возвращённых тикетов превышает все разумные пределы — опять-таки, это не проблемы code review, вам снова к тимлиду.
N>Это проблемы всей группы и сваливать их лично на тимлида — конечно, работает, но недолго.
Ок, перефразирую так: решение таких вопросов — это уже ответственность тимлида. Как он решит разбираться: с привлечением всей команды, изменением процесса разработки, или беседой с отдельными товарищами — здесь не так уж и важно. Ключевой момент: эта проблема организационная и способ её решения должен определять тимлид.


S>>3. Если тикет прошёл проверку у тестеров, его как раз и стоит отправлять в очередь на review. Если прошёл — всё ок. Не прошёл — возвращаем на доработку, см предыдущиий пункт.
N>У каких таких заек тестеров? Автотесты в рамках CI или аналога? Не вижу причин не делать это одновременно.
Автотесты, интеграционные, ручное тестирование (для сложных фич). Порядок тесты-review в принципе не так уж и важен.

N>Не понимаю. Совершенно нормальная ситуация: исправление разложено на группу коммитов. У меня недавно одна такая правка разложилась на 18 коммитов, каждый из которых менял что-то настолько мелко, что было тривиально её прочесть. И тем не менее на ревью было получено и отработано несколько полезных замечаний.
N>Зачем пугаете страстями непонятного характера?
Я ведь подстраховался выше: "Если очень хочется, можно поменять пункты 2 и 3 местами. Из моей практики — это не всегда удобно.". Регулярно в промежуточный коммит уходят изменения, которые просто нет смысла просматривать до завершения всего тикета, т.к. код будет меняться не раз и не два.

S>>Это лечится очень просто — достаточно, чтобы тикет нельзя было закрыть без прохождения code review.
N>Простите, я не понимаю вашего workflow.
Грубо говоря: очередь разработки — разработка — очередь тестирования — тестирование — очередь на review — review — закрыт.

N>В моём варианте ревью назначается на коммит, а не тикет.
Если назначать review на отдельный коммит, то приходится увязывать жизненный цикл тикета "проверить коммит XXXXX (тикет YYYYY)" с собственно тикетом YYYYY. Если у вас это работает — классно.

On 12.12.2012 11:59, enji wrote:

> А можно поподробней?
Поподробнее. При двух человеках — это типичнейшая ИБД.

> Что именно не так, как сделать лучше?
Что сделать и лучше чего?

Здравствуйте, enji, Вы писали:

E>Здравствуйте, Kernan, Вы писали:

K>>Здравствуйте, enji, Вы писали:

E>>>Есть какое-то платное дополнение к Жире, но чего-то жалко денег. Вроде как набор скриптов для моих пунктов не так уж и сложно будет написать. За неделю наверное справлюсь...
K>>У нас был винрарнеший инструмент reviewboard, рекомендую.
E>Вот на него то я и смотрел. Что-то он меня не особо впечатлил. Говоришь — удобно?
Так он простой как валенок, поэтому им удобно пользоваться. Я говорю как пользователь. Настраивать не приходилось.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, netch80, Вы писали:

S>В основном возразить нечего, процесс разработки — это всё-таки вопрос предпочтений, так что отвечу на вопросы — и давайте закругляться

Тут таки не просто предпочтения, а некоторое взаимное непонимание, так что разберу по деталям.

S>>>2. Если человек в коммит кидает откровенную ересь, которая не соответствует описанию задачи в тикете — тикет просто возвращается ему на доработку.
N>>Простите, возвращается *тикет* или *коммит*?
S>Конечно же тикет, коммит уже сделан. Выпилить уже сделанный коммит или полноценно проверить код до коммита — не вариант, согласитесь.

Именно что вариант, если средствами типа gerrit собственно коммит ещё не принят, пока не одобрен. На этапе проверки он фактически хранится в персональной ветке и не попадает в основное дерево целевой ветки.
Возможно, это вам неприемлемо, но тогда надо обсуждать именно причины этой неприемлемости.

S>>>3. Если тикет прошёл проверку у тестеров, его как раз и стоит отправлять в очередь на review. Если прошёл — всё ок. Не прошёл — возвращаем на доработку, см предыдущиий пункт.
N>>У каких таких заек тестеров? Автотесты в рамках CI или аналога? Не вижу причин не делать это одновременно.
S>Автотесты, интеграционные, ручное тестирование (для сложных фич). Порядок тесты-review в принципе не так уж и важен.

OK. Но одобрение без автотестов не имеет смысла.

N>>Не понимаю. Совершенно нормальная ситуация: исправление разложено на группу коммитов. У меня недавно одна такая правка разложилась на 18 коммитов, каждый из которых менял что-то настолько мелко, что было тривиально её прочесть. И тем не менее на ревью было получено и отработано несколько полезных замечаний.
N>>Зачем пугаете страстями непонятного характера?
S>Я ведь подстраховался выше: "Если очень хочется, можно поменять пункты 2 и 3 местами. Из моей практики — это не всегда удобно.". Регулярно в промежуточный коммит уходят изменения, которые просто нет смысла просматривать до завершения всего тикета, т.к. код будет меняться не раз и не два.

Почему нет смысла просматривать? Если к ним адекватно объяснено, почему оно такое, и что это только промежуточная стадия, то вполне имеет смысл.

S>>>Это лечится очень просто — достаточно, чтобы тикет нельзя было закрыть без прохождения code review.
N>>Простите, я не понимаю вашего workflow.
S>Грубо говоря: очередь разработки — разработка — очередь тестирования — тестирование — очередь на review — review — закрыт.

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

N>>В моём варианте ревью назначается на коммит, а не тикет.
S>Если назначать review на отдельный коммит, то приходится увязывать жизненный цикл тикета "проверить коммит XXXXX (тикет YYYYY)" с собственно тикетом YYYYY. Если у вас это работает — классно.

У нас отдельных тикетов на "проверить коммит", они не имеют смысла.

Здравствуйте, Vzhyk, Вы писали:

О великий учитель, разъясни мне, неразумному (ОВУРМН)

>> А можно поподробней?
V>Поподробнее. При двух человеках — это типичнейшая ИБД.
ОВУРМН, почему? С учетом появления третьего вначале проще обкатать на двух...


>> Что именно не так, как сделать лучше?
V>Что сделать и лучше чего?

ОВУ, а читал ли ты самое первое сообщение?

Пытаюсь потихоньку внедрить ревью кода.
...

Чего не устраивает:
* Ю должен не забыть позвать С перед пушем
* Истории замечаний нет. Ю должен не забыть поправить их все. С должен не забыть, что ж там были за замечания, чтобы их проверить
* Когда коллектив прирастет новым членом — бардак усилится

------------
Ты это, если взялся отвечать, не мог бы простым русским языком написать, чего не так? Без загадок и непонятных встречных вопросов

Здравствуйте, netch80, Вы писали:

N>Тут таки не просто предпочтения, а некоторое взаимное непонимание, так что разберу по деталям.
Ок, давайте

N>Возможно, это вам неприемлемо, но тогда надо обсуждать именно причины этой неприемлемости.
Угу, понял о чём речь. Вполне приемлемо, если не ставить задачу документировать сам факт code review в тикете.

S>>Автотесты, интеграционные, ручное тестирование (для сложных фич). Порядок тесты-review в принципе не так уж и важен.
N>OK. Но одобрение без автотестов не имеет смысла.
Разумеется

S>>Регулярно в промежуточный коммит уходят изменения, которые просто нет смысла просматривать до завершения всего тикета, т.к. код будет меняться не раз и не два.
N>Почему нет смысла просматривать? Если к ним адекватно объяснено, почему оно такое, и что это только промежуточная стадия, то вполне имеет смысл.
Ну... да Загвоздка в том, что далеко не всегда в промежуточных коммитах люди скидывают законченный код — там осталась заглушка, тут, наоборот оставлен старый код и к нему навёрнута заплата... Понятно, что в идеальном мире такого быть не должно. С другой стороны, если к конечному результату не придраться — стоит ли напрягать людей по мелочам?

S>>>>Это лечится очень просто — достаточно, чтобы тикет нельзя было закрыть без прохождения code review.
N>>>Простите, я не понимаю вашего workflow.
S>>Грубо говоря: очередь разработки — разработка — очередь тестирования — тестирование — очередь на review — review — закрыт.

N>Понятно. Нам это неприемлемо: обычное ревью должно происходить после автотестирования, но до ручного тестирования.
Я повторюсь, порядок непринципиален. Главное, чтобы сам факт code review был отражён в тикете.

Здравствуйте, Kernan, Вы писали:

E>>Вот на него то я и смотрел. Что-то он меня не особо впечатлил. Говоришь — удобно?
K>Так он простой как валенок, поэтому им удобно пользоваться. Я говорю как пользователь. Настраивать не приходилось.

А не мог бы ты тогда вкратце описать, чего он предоставляет пользователю?

Насколько я понял из описания, автор кода создает запрос на ревью, к нему крепятся дифы изменений, ревьюверы делают комментарии, автор правит код, крепятся новые дифы и т.д.

Вопрос — чем это сильно лучше таска в жире?

Здравствуйте, enji, Вы писали:

E>Чего не устраивает:
E>* Ю должен не забыть позвать С перед пушем
А что объективно может случиться, если код будет запушен без ревью? Не на уровне "в репо будет не очень хороший код", а на уровне "код с ошибками может уйти в production". В целом это вроде как совсем не проблема. Изменения от юниора будут видны в тот момент, когда С будет делать pull в свой репозиторий. Там можно будет и тикет создать нужный, чтобы про него не забыть. И это будет работать, если у вас Ю не может сам продукт релизить. Я, например, уже давно "просто pull" не делаю, всегда просматриваю входящие изменения (ака synchronize в ide).

E>* Истории замечаний нет. Ю должен не забыть поправить их все. С должен не забыть, что ж там были за замечания, чтобы их проверить
Ну нет. Листочек + комментарии в коде прекрасно проблему решают без лишних накладных расходов. На листочке ваш Ю может пунткы отмечать. В коде — обозначать специальным тегом и искать по нему (или IDE настроить, чтобы комментарии правильно выводились). Для С не факт, что список замечаний нужен. Гораздо удобнее выполнять ревью смотря на diff <current> <baseline>, а не на последние коммиты по-отдельности. Там что-то ранее пропущенное может выясниться. Так что и пропущенные замечания будут найдены. Можно еще листочек попросить и посмотреть, тоже не большая проблема. А комментарии в коде можно сразу в локальный repo закоммитить для истории и потом по коммиту смотреть.

E>* Когда коллектив прирастет новым членом — бардак усилится
А в чем бардак? Отличная неформальная схема (схему вы изложили сами). Ненужных для команды артефактов не создает. Да, вам не видно работы по ревью. Оно вам надо? Что именно вы получите, заставив участников "имитировать активность"? Смотрите. У вас в схеме сейчас С отвечает за общее качество кода (определяет опасные задачи и требует "ревью"). С же является наставником Ю. До тех пор, пока вас общий результат работы С устраивает (код нормального качества, Ю учится), не надо лезть в процесс. Вот если вы на самом деле получите объективные проблемы, тогда стоит обсудить ситуацию с С и поискать пути решения. А так — может он еще троих Ю потянет без проблем.

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

И обсудите вашу проблему с командой (С и Ю). Расскажите им, чего именно вы боитесь. Может быть, вы на самом деле боитесь зря. А если не зря (были случаи пропущенных коммитов и прочих неприятностей из-за ненадлежащего ревью), нужно это все опять же озвучить команде. Проблемы роста при растущей команде (нет времени, что-то забывается и т.п.) при нормальных отношениях внутри команда решит. Если будет знать, что вы готовы ей в этом помочь — еще лучше. Тогда вы о начавшихся проблемах можете узнать достаточно рано (т.е. даже без самостоятельных попыток команды решить проблему). Кстати, инстурменты для ревью в первую очередь должна тоже выбирать команда, а не вы. Ведь С же будет делать ревью? Вдруг то, что удобно вам, будет очень не удобно ему? Или не будет отвечать его требованиям?

Здравствуйте, enji, Вы писали:

E>>>Пытаюсь потихоньку внедрить ревью кода. Сейчас коллектив состоит из двух человек — сеньора (С) и юниора (Ю). Используется меркуриал — локальные репы у каждого + центральный реп на сервере, с которым все синхронизируются.

E>>>Что думаете по этому поводу? Как можно улучшить? Может быть есть что-то готовое, работающее примерно в таком ключе и с меркуриалом?
IS>>если команда маленькая, то можно остановиться на неформальном post review.
E>Пост-ревью не сильно нравится тем, что если Ю накосячит, спрос будет в основном с С. Т.е. С таки надо просматривать все, причем перед выходом наружу. А это подводит нас ко второму моменту

IS>>когда у C есть время, он просто садиться рядом с Ю и проходит через последние комиты оного,
E>Вот это не нравится. Много проектов, за неделю иногда релизится 3-4 версии. Надо где-то отдельно помнить — "надо просмотреть коммиты". Для жировских же тасков уже сделаны напоминалки и планирование.

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

Здравствуйте, netch80, Вы писали:

IS>>если команда маленькая, то можно остановиться на неформальном post review. когда у C есть время, он просто садиться рядом с Ю и проходит через последние комиты оного, вместе смотрят дифы, обсуждают, предлагают как переделать по хорошему на будушее или же переделывают на ходу. В последствиии тоже самое может начать делать и сам Ю.

N>Требует очень высокой дисциплины по выделению времени на такое ревью, причём не только сразу, а и через много лет (если не отменено). По этой причине практически нереализуемо на практике без погонялы с хлыстом.

не понял про дисциплину и выделение времени.

Здравствуйте, enji, Вы писали:

E>Здравствуйте, Kernan, Вы писали:

E>>>Вот на него то я и смотрел. Что-то он меня не особо впечатлил. Говоришь — удобно?
K>>Так он простой как валенок, поэтому им удобно пользоваться. Я говорю как пользователь. Настраивать не приходилось.

E>А не мог бы ты тогда вкратце описать, чего он предоставляет пользователю?

E>Насколько я понял из описания, автор кода создает запрос на ревью, к нему крепятся дифы изменений, ревьюверы делают комментарии, автор правит код, крепятся новые дифы и т.д.
Там есть построчные коментарии. Например, выделяешь строку и пишешь "тут ты забыл то-то". Каждый коментарий виден в списке коментов и напротив него можно начать дискусию (в виде дерева это всё). Мы ре-ревью не делали по причинам, которые я описал выше.

E>Вопрос — чем это сильно лучше таска в жире?
Удобно. Кстати, если у вас разработка идёт в виде бранч-на-таск, то там можно просто указать мастер бранч и дев бранч, а система всё прикрепит сама. Правда мы работали с git. У нас даже скрипт был для сабмита ревью, просто вызываешь скрипт и он сам всё создаёт.

Здравствуйте, enji, Вы писали:

E>Вот на него то я и смотрел. Что-то он меня не особо впечатлил. Говоришь — удобно?

Вполне неплохо. Ставится с полпинка (единственный затык был с LDAP авторизацей). Ну и post-review очень удобный инструмент (кроме тех несчастных душ, которые на Windows)

Здравствуйте, enji, Вы писали:

E>Пытаюсь потихоньку внедрить ревью кода. Сейчас коллектив состоит из двух человек — сеньора (С) и юниора (Ю). Используется меркуриал — локальные репы у каждого + центральный реп на сервере, с которым все синхронизируются.

У нас Code Coolborator и все настроено так, что ни одного коммита без review в принципе быть не может.

А так может иметь две ветки, Main и Sandbox. (Ю) коммитит в Sandbox, reviewer переносит в Main.

Здравствуйте, Igor Sukhov, Вы писали:

IS>>>если команда маленькая, то можно остановиться на неформальном post review. когда у C есть время, он просто садиться рядом с Ю и проходит через последние комиты оного, вместе смотрят дифы, обсуждают, предлагают как переделать по хорошему на будушее или же переделывают на ходу. В последствиии тоже самое может начать делать и сам Ю.

N>>Требует очень высокой дисциплины по выделению времени на такое ревью, причём не только сразу, а и через много лет (если не отменено). По этой причине практически нереализуемо на практике без погонялы с хлыстом.

IS>не понял про дисциплину и выделение времени.

Не понимаю, что тут непонятного. Если не будет этой дисциплины, то ревью кода, который чуть старее чем два дня назад, не будет выполняться вообще, потому что постоянно будут поступать новые задачи, которые приоритетнее.

Здравствуйте, enji, Вы писали:

E>Что думаете по этому поводу? Как можно улучшить? Может быть есть что-то готовое, работающее примерно в таком ключе и с меркуриалом?

Прости, но это какая-то порнография. Есть же pull requests. Юниор коммитит в ветку и когда все готово создает pull request. Синьор вытаскивает изменения, проверяет и если все ОК вливает их в мастер. Если не OK он пишет к pull request'у комментарий. Ничего нигде не провисает, ничего нельзя забыть, все логгируется. В Jira + Cubicle этот workflow автоматизируется из коробки.

Здравствуйте, maxkar, Вы писали:

E>>Чего не устраивает:
E>>* Ю должен не забыть позвать С перед пушем
MИ это будет работать, если у вас Ю не может сам продукт релизить.
У нас много относительно "мелких" продуктов. Программист выпускает новую версию, она идет тестерам. Если есть замечания — программист их правит и выдает новую сборку той же версии. Если нет — то последняя проверенная сборка идет в релиз. Версии выпускают оба, и Ю и С. Но в принципе наверное стоит вставить в воркфлоу тестирования дополнительный этап — ревью, без которого тестирование не закончится.

E>>* Когда коллектив прирастет новым членом — бардак усилится
M>А в чем бардак? Отличная неформальная схема (схему вы изложили сами). Ненужных для команды артефактов не создает. Да, вам не видно работы по ревью. Оно вам надо?
Я — это С в данной истории Мне больше нравится, когда все мои задачи пропускаются через трекер. При этом:
* о получении задачи я уведомляюсь, причем не требуется тут же отвлечься от текущей работы и чего-то сказать
* есть план выполнения задач, новые задачи в него вставляются
* есть напоминалка о несделанном
* можно отметить затраченное время и потом прикинуть, куда оно ушло

M>И обсудите вашу проблему с командой (С и Ю).
С юниором действительно надо обсудить. Просто сначала хотелось самому определиться со своими хотелками и послушать критику и предложения

Здравствуйте, Sinix, Вы писали:

N>>Возможно, это вам неприемлемо, но тогда надо обсуждать именно причины этой неприемлемости.
S>Угу, понял о чём речь. Вполне приемлемо, если не ставить задачу документировать сам факт code review в тикете.

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

С другой стороны, может идти речь о каком-то принципиальном выборе решения, которое требует ревью и которое влияет на то, в какую сторону будут идти коммиты. Да, это может быть темой тикета. Но это уже вообще-то не code review. Это, например, architectural review и оно делается несколько на другом уровне логики (а в структурах с жёстким разделением уровней — и на более высоком уровне людей, без кодеров).

S>Ну... да Загвоздка в том, что далеко не всегда в промежуточных коммитах люди скидывают законченный код — там осталась заглушка, тут, наоборот оставлен старый код и к нему навёрнута заплата... Понятно, что в идеальном мире такого быть не должно. С другой стороны, если к конечному результату не придраться — стоит ли напрягать людей по мелочам?

Да, такое постоянно. Вот потому и надо писать в commit message, что "тут оставлена заглушка", "эта заплата — до следующей реформы, которая по плану через месяц", и тому подобное.
Это лучше, чем не писать и полагаться на ревью всей цепочки для тикета, потому что
1) кроме непосредственного выполнения задач для тикета есть ещё масса других аспектов, которые требуют контроля
2) когда через год-два будет анализироваться код на тему "откуда вот это переехало и почему", грамотное сообщение поможет понять причину конкретного решения без того, чтобы погружаться заново в контекст всего тикета. А такие ситуации с анализом старого — значительно чаще, чем хочется того.

А чтобы некоторые другие аспекты сложного цепочечного изменения были понятны — можно отправлять полный набор коммитов для тикета (или его крупной части) целиком. Кстати, эта практика — стандартная в LKML: изменение делится на последовательность элементарных действий, каждое из которых достаточно тривиально, чтобы быть проверенным в одиночку, и поверх них пишется письмо-описание (cover letter) с общим смыслом предложенного. Для понимания вначале читается письмо-описание, затем разбираются отдельные коммиты. Но в моей практике оказалось достаточно отправлять по частям и, если кому-то что-то непонятно, объяснять в дискуссии.

S>>>>>Это лечится очень просто — достаточно, чтобы тикет нельзя было закрыть без прохождения code review.
N>>>>Простите, я не понимаю вашего workflow.
S>>>Грубо говоря: очередь разработки — разработка — очередь тестирования — тестирование — очередь на review — review — закрыт.

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

N>>Понятно. Нам это неприемлемо: обычное ревью должно происходить после автотестирования, но до ручного тестирования.
S>Я повторюсь, порядок непринципиален. Главное, чтобы сам факт code review был отражён в тикете.

В варианте, когда ревью идёт на коммит, иначе и быть не может. Точнее, конечно, может быть безумец, который зарезолвил тикет ничего не сделав, но QC (тестеры) это поймёт в 1-2 дня, и недобросовестный исполнитель так долго в конторе не проживёт.

Здравствуйте, netch80, Вы писали:

IS>>>>если команда маленькая, то можно остановиться на неформальном post review. когда у C есть время, он просто садиться рядом с Ю и проходит через последние комиты оного, вместе смотрят дифы, обсуждают, предлагают как переделать по хорошему на будушее или же переделывают на ходу. В последствиии тоже самое может начать делать и сам Ю.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, enji, Вы писали:

E>>Что думаете по этому поводу? Как можно улучшить? Может быть есть что-то готовое, работающее примерно в таком ключе и с меркуриалом?

А>Прости, но это какая-то порнография. Есть же pull requests. Юниор коммитит в ветку и когда все готово создает pull request. Синьор вытаскивает изменения, проверяет и если все ОК вливает их в мастер. Если не OK он пишет к pull request'у комментарий. Ничего нигде не провисает, ничего нельзя забыть, все логгируется. В Jira + Cubicle этот workflow автоматизируется из коробки.

Ну дык я практически об этом и говорю. Единственное — меня душит жаба покупать крубикл.

Здравствуйте, enji, Вы писали:

E>Ну дык я практически об этом и говорю. Единственное — меня душит жаба покупать крубикл.

Говорят gitlab умеет pull requests из коробки.