коде ревью перед коммитом , как сделать коде ревью перед коммитом в основную ветку другого участника команды?

доброго времечка господа.

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

Как это реализовать и какую систему хранения версий использовать?

Есть такой весьма неплохой инструмент: Code Collaborator. Он платный (наверняка есть бесплатные аналоги). Предназначен как раз для осуществления описанного тобою процесса. Может работать в связке с СКВ в том числе и в варианте, когда коммит не проходит, пока не закрыто ревью.

Цитата

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

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

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

Ну, как бы если есть ОДИН ответственный за продакшн (он же - старший программист из постановки задачки), то холиваров возникнуть не должно.

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

Сообщение отредактировано: Бобёр - 08.06.11, 20:35

с этим хорошo справляется polarion.
а вообще в принципе, например, для eclipse есть jupiter.

Цитата Бобёр @ 08.06.11, 20:32

Ну, как бы если есть ОДИН ответственный за продакшн (он же - старший программист из постановки задачки), то холиваров возникнуть не должно.

Если продакшен-кода - десятки/сотни мегабайт, коммитеры исчисляются десятками или сотнями, то один "ответственный" физически не сможет ни за что отвечать.

Цитата Flex Ferrum @ 09.06.11, 13:24

Если продакшен-кода - десятки/сотни мегабайт, коммитеры исчисляются десятками или сотнями, то один "ответственный" физически не сможет ни за что отвечать.

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

Цитата Машина @ 09.06.11, 13:28

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

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

как уже сказал Флекс, старший программист может проверить только тогда, когда это очень маленький проект. В реальной же жизни так не получается. У нас это, например, работает так: каждый кусок кода должен быть проверен другим программистом, можно это делать приграммно, можно визуально, а можно весъ процесс одной прораммой контролировать (мы пользуемся polarion). параллельно должны быть созданы/проверены программерские юнит-тесты, потом весъ код идет в билд и к нашему тест-тиму.

Цитата

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

Я там в клубе ссылочку давал, русский перевод концепии "Programming, Mothefacker"

Цитата

Если продакшен-кода - десятки/сотни мегабайт, коммитеры исчисляются десятками или сотнями, то один "ответственный" физически не сможет ни за что отвечать.

Ну, в исходной задаче не стояла цель "закоммитать сразу везде и т.д.", человек явно работает над каким то одним проектом.
А у вас всё собирается "в одной большой куче" что ли? Т.е. ночью билд система берёт, выгружает самые последние исходники "на сегодня" в одну кучу и пытается их собрать? Обычно же явно указываются, скажем, точная версия такой то подсистем X, Y, P, которая нужна для сборки проекта F. Как оно может не собраться в такой ситуации?

Вот, кстати, git могу ещё раз прорекламировать - у тебя есть проект, есть к нему субмодули (субмодули хранятся в своих репо, и разрабатываются отдельно), ты указываешь точную версию подсистемы которая нужна В ТВОЁМ ЛИЧНОМ ПРОЕКТЕ. Если самая свежая версия подсистемы тебя не устраивает, ты просто её не берёшь. А если обновляешь - тупо проверяешь её работоспособность.

немного поясню к чему этот вопрос.

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

Я хочу внести изменения, что бы работа проводилась командами по 2-3 человека, один из них будет ведущим, который и будет делать коде-ревью.

Ведущий будет смотреть исключительно за кодом тех кто работает с ним в команде, т.е. проводить ревью кода по проекту, которым он занимается и смотреть код не более 2-х человек.

Code Collaborator посмотрел, но что-то он тяжеловат для подобной простой задачи. У нас в подразделении не более 8-ми человек и планируется организовать пробную команду из 3-х человек, вот хочется в этой команде и организовать коде-ревью.

Кстати, может посоветуете что почитать хорошего по поводу организации команд и т.п.?

Ок, а что тогда у вас вообще есть? Билд система? Система контроля версий? Система непрерывной интеграции? Документации?
Как я понял, это что то вроде стартапа, правильно?

В git такая штука 100% настраивается и, если я не ошибаюсь, без сторонних плагинов.
Надо курить в эту сторону.

С гитом хорошо идёт gerrit.