?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


melkus
melkus at 2011-06-19 14:00 (UTC) (Link)
>Достаточно запретить все коммиты, в комментариях к которым не указана фамилия проверяющего.

А как технически осуществляется доставка кода проверяющему, его же может быть много? Или просто позвать за свой комп?
Gaperton
gaperton at 2011-06-19 14:26 (UTC) (Link)
Например - через систему контроля версий, привязку коммита к тикету, и переназначение тикета на проверяющего, который перенесет коммит в главную ветку.

Есть и другие варианты с использованием спецсредств, например, Atlassian Crucible.

А можно показать изменения с экрана своего компьютера, и заодно объяснить их - это самое простое.
melkus
melkus at 2011-06-19 14:38 (UTC) (Link)
Меня пугает сложность всего этого, коммит в спец ветку, потом переброс кода в основную. Он конечно гарантирует то что код будет просмотрен, но нужна ли нам эта гарантия за эти накладные расходы?
Gaperton
gaperton at 2011-06-19 16:22 (UTC) (Link)
Первая схема опирается на схему репозитория с параллельными ветками dev/release. Ровным счетом ничего страшного. dev - это trunk, туда делается коммит с пост-коммит ревью.

Накладных расходов почти нет - ревью делается тычками в файлы коммита в описании задачи в трекере. Ссылки ведут на diff в вебморде VCS. Это - результат интеграции трекера и VCS. И это действительно удобно. Людям нравится.

Crucible, и прочие тулы для code review, позволяет реализовать более гибкие схемы.
melkus
melkus at 2011-06-20 08:31 (UTC) (Link)
Ага понял, т.е. заранее закладывается в накладные расходы что есть отдельно dev/release и вечный merge. Согласен, тут мало накладных расходов, это не слияние двух веток после 3 месяцев независимого существования.

Я правильно понимаю что dev ветка заводится только под багфиксинг?
Потому что если там колбасить новый код или например менять архитектуру то может пойти сильное расхождение с release веткой, что сделает невозможным быстрый перенос кода по некоторым модулям.
dr.chaos
dr_cha0s at 2011-06-22 09:05 (UTC) (Link)
Ну для этого как минимум раз в неделю надо в отдельную ветку всасывать изменения из главной ветки.
Gaperton
gaperton at 2011-06-22 21:36 (UTC) (Link)
> Я правильно понимаю что dev ветка заводится только под багфиксинг?

Нет. Под все.

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

Для длинных изменений как и в обычной ситуации надо заводить feature branch, И никаких вариантов здесь нет. Невозможно делать "быстрый перенос" не тестированного кода с "изменениями архитектуры" ни в какой схеме.
melkus
melkus at 2011-06-24 12:45 (UTC) (Link)
Ага, понятно.
Немного не по теме:
Мне кажется или Вы работает в крупных проектах?
Я просто пытаюсь на себя примерить и понимаю что некоторые вещи полезны, но не сейчас, а когда скажем будет человек 20 в команде.
Gaperton
gaperton at 2011-06-24 14:13 (UTC) (Link)
Я работал в самых разных проектах начиная с 96 года. Вас интересует, начиная с какого объема команды перечисленное начинает приносить практическую пользу?

Начиная с 6-10 человек уже целесообразно. И надо добавить, что я говорю про случай, когда работа не носит заказной и разовый характер, а подразумевает последующую поддержку и развитие написанного.
hedgeov
hedgeov at 2011-06-19 19:16 (UTC) (Link)
Если есть соглашение "тикет на отдельной ветке" -- проверяющему высылается имя ветки, которую надо смотреть. При этом процесс может выглядеть так: Тикет имеет состояния "решено", "ревьюировано" и "интегрировано". Ревью имеет свой собственный жизненный цикл с состояниями "создано", "состоялось", "отклонено", "исправлено", "закрыто". Ревью разрешается инициировать когда у тикета состояние "решено". Ревью создается, при этом указывается имя ветки, в которую надо смотреть. После того как ревьюер посмотрел в указанную ветку и налабал массу замечаний, ревью считается "состоявшимся". После того как автор все замечания устранил на той же самой ветке, ревьюер смотрит на результат и либо меняет состояние на "исправлено", либо на "отклонено". Если "отклонено", то автор продолжает исправлять, пока ревьюер не согласится. Если состояние "исправлено", то автор закрывает ревью (переводит в состояние "закрыто"). После этого, когда тикет в состоянии "исправлено" и ревью в состоянии "закрыто", можно мержить изменения с ветки в trunk, после чего переводить тикет в состояние "смержено". Для перевода в состояние "смержено" обязательно указывается номер ревью.
melkus
melkus at 2011-06-20 08:33 (UTC) (Link)
В случае если фикс занимает 10 минут, что иногда встречается, проще позвать человека к своему монитору. Ваш вариант мне нравится когда я начинаю думать о больших изменениях, а использовать ветки для багов и мелких тикетов мне кажется расточительством.
hedgeov
hedgeov at 2011-06-20 09:13 (UTC) (Link)
Я за унифицированный процесс вне зависимости от сложности изменений. "В каждом безобразии должно быть единообразие" -- когда процесс один и без исключений -- его проще запомнить и применять. Опять же, не всегда ревьюер физически способен к монитору подойти (из другой страны он например). На самом деле не так много времени это веткотворение занимает.

Самый большой плюс веток на мой взгляд -- простота разбора коллизий, возможность быстро и безболезненно выкинуть кривой багфикс если что-то пошло не так. Если все изменения на mainline -- просто так середину не выкинешь и придется сравнительно долго согласовывать между авторами откаты и перевнесение изменений.
Previous Entry  Next Entry