Как правильно коллективно производить разработку?

Правильная технология - это когда каждый разработчик разрабатывает фичу в локальной ветке, потом она проходит code review и ребейзится в мастер, при этом полезно в качестве системы ревью использовать Gerrit, который проконтролирует права доступа и не даст запушить ничего лишнего в общие ветки

А долгоживущие ветки, в которые все подряд пушат сырой код - это пережиток нераспределенных VCS

1. есть ветка main
2. прочие ветки формируются из main, в них ведётся разработка
3. после создаётся pull request, проходит code review, тестирование и всё прочее. Потом слияние в main
4. Всё прочие pull request синхронизируется с main по необходимости. (если есть конфликты, или если произошли ещё какие-то изменения, если CI не проблема, и не нужно укладываться в квоты, то можно всегда синхронизироваться)

при этом полезно в качестве системы ревью использовать Gerrit

Ни в коем случае и ни при каких условиях.

Собственно, да.

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

+1

Gerrit - Ни в коем случае

+1

Мне кажется, что главная ваша проблема не в ветках, а в

Далее тестируем в dev

Звучит это так, как будто все тесты выполняются руками какой-то группой людей (QA + dev?). Полезно подумать о написании набора тестов, которые сможет автоматически выявлять дефекты в уже разработанном функционале. Тогда «Далее тестируем в dev» можно будет заменить на «перед мержджем изменений в дев происходит его автоматическое тестирование».

Но написание и поддержание набора тестов в рабочем виде не бесплатно. Необходимо искать баланс для вашего конкретного приложения.

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

Так и есть.

Как быть в этом случае? Какая вообще правильная технология коллективной разработки?

Правильного нет. У тебя два фактора здесь:

• изоляция тестирования
• уменьшение количества тестовых стендов

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

Только вот в твоей схеме тестирования нет. В master всё то же взаимовлияние изменений.

Тогда «Далее тестируем в dev» можно будет заменить на «перед мержджем изменений в дев происходит его автоматическое тестирование».

Это в идеальном мире. В реальности это выйдет ещё дороже, чем 9000 тестовых серверов.

Читать Trunk Based Development до просветвления.

Только вот в твоей схеме тестирования нет.

Для этого есть CI, который может работать перед интеграцией в мастер (как в Qt) или после нее (и тогда брак откатывают)

CI

Нагрузочное тестирование потянет?

Как правильно коллективно производить разработку?

Правильно голландский штурвал устроить.

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

Любое потянет, если автоматизированное.

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

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

Автотесты производительности запускаются на конкретном агенте, стоящем на реальном железе, которое годами не изменяется

Gerrit хорош и пригож.

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

Так а если вы протестировали каждый отдельно, а потом слили в мастер - получили тот же "нестабильный" код. Лучше уж если это в dev'е произойдет.

Тестировать можно и ту ветку, где ведется разработка, она же представляет собой "рабочее состояние + нужные изменения". Если тест новой фичи (этой ветки) проходит - да, потом сливается во всякие тем "предпроды" и тестируется уже весь набор изменений, который уйдет в релиз. Вообще сколько таких сред зависит в целом от договоренностей команды и требований бизнеса, по сути то вам никто не мешает вообще в мастер сразу фигачить.

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

О, годнота!

Gerrit хорош и пригож.

Чем докажешь свой тезис?

eсть ветка main

уже и сюда притащили этот ньюспик

Gerrit похож на творение фаната HTML 1.0. А пользоваться им — сплошное мучение, потому как переизобретённые коммиты и ветки плохо согласуются с уже имеющимися в git.

Мифическое 100% покрытие исповедуешь? Это наивный тупак.

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

Мифическое 100% покрытие исповедуешь? Это наивный тупак.

Тупак-то тупак, спору нет, но речи про 100% покрытие вроде и не было.

Потому там и стоит знак вопроса.

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

Мифическое 100% покрытие исповедуешь?

Да б-же упаси

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

Это вопрос чисто релиз-менеджмента, можно гонять мастер в продакшене а дев на стейджинге (если ты такой весь из себя CD), а можно в продакшене гонять проверенные теги с мастера, или даже создавать релизные ветки от мастера, как в том же Qt например

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

Это не раздолбайство, а рациональный подход с минимумом ненужных веток и линейной историей, с которой легко работать.

А если у них при этом ещё и стейджинга нет, то это уже явный саботаж.

Какой стейджинг нужен проекту, не являющемуся сервисом? Собирается тег с мастера и отдается тестировщикам (или пользователям-энтузиастам). Если какая-то сложная фича, то разраб может отдать сборку своей персональной ветки тестерам, а уже после этой начальной проверки начинать интеграцию.

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

Какой стейджинг нужен проекту, не являющемуся сервисом?

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

Если какая-то сложная фича, то разраб может отдать сборку своей персональной ветки тестерам

А потом слиться с мастером и тестить по-новой. 👍

Та же фигня с избранным тегом из нестабильного мастера. Отдал ты тег на тестирование, он бажный, и вот у тебя два пути. Первый — создать от тега бранч просто ради того, чтобы его попатчить, — такое себе. Второй — патчить тут же в мастере, — вообще тупик, так как со времени твоего тега окажется ещё что-нибудь слито, а там опять баг, который нужно патчить, а в мастер (surprise, muthafucka!) опять успели что-то слить, и так до бесконечности.

Gerrit похож на творение фаната HTML 1.0.

Это плюс. Чистый, свободный и высокопроизводительный интерфейс.

плохо согласуются

Gerrit подразумевает определённый рабочий процесс. Следуйте процедуре и волосы будут гладкими и шелковистыми.

Это плюс.

Нет, это минус.

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

Gerrit подразумевает определённый рабочий процесс.

Да. Стоя, в гамаке, в ластах.

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

Ну да, геррит не свистит и не пердит, но дело свое делает.Но вам, фанбоям мака, главное шашечки, а не ехать.

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

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

Да. Стоя, в гамаке, в ластах.

Чепуха, при правильном использовании на геррит вообще внимания обращаешь, просто рассматриваешь код и ставишь +1,-1. Т.е. выполняешь свои непосредственные обязанности.

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

Это не специалисты по интерфейсу, это художники.

при правильном использовании на геррит вообще внимания обращаешь

Да, а я не хочу обращать внимание на подобный глубоко вспомогательный инструмент.

(да, я понимаю, что ты случайно пропустил «не», но результат получился неожиданно точный)

просто рассматриваешь код и ставишь +1,-1

Для тебя, возможно, это станет сюрпризом, но в Гитхабе это делается так же, только удобнее.

Ну да, геррит не свистит и не пердит, но дело свое делает.

Как раз пердит он слишком много.

только удобнее.

Не вижу разницы.

А что не так с геритом?

Он говно.

И по внешнему виду, и по функциональности.

Примеры:

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

По ошибке вместо git commit --amend делаешь просто git commit. У тебя теперь два CR-a (это такие переизобретённые герритом PR-ы, потому что NIH), и полная каша в результате. Гитхаб нормально работает со стандартым git-овым workflow.

Посмотреть blame в геррите можно, но вот посмотреть, что было РАНЬШЕ — укликаться можно. В гитхабе это делается в один клик. Точно так же, в гитхабе ты можешь сначала отметить строчку, а потом посмотреть blame — и гитхаб сразу вернёт тебя к этой же строчке. В геррите тебе придётся заново её искать.

Попросить ревьюера посмотреть твой CR заново? В гитхабе это один клик (с недавних пор). В геррите — успехов с этим. Не говоря уже о том, что ревью тоже пропадает, если автор чуть-чуть пофиксил. В результате варианты «одобряю с условием, что вот эта опечатка будет поправлена» не проходят.

И такого — вагон и маленькая тележка. В целом, геррит производит впечатление сделанного на отъеби&ь, по сравнению с гитхабом.

Хм... Очень странные претензии как по мне. Должен отметить что мое отношение к пулл-риквестам вообще условно-негативное, я перфекционист и борец за чистоту каждого комита...
Так вот, основная разница между процессом построеном на основе герита и гитлаба заключается в том что герит он комитоцентричен, а гитлаб он опирается на концепцию слияния веток, aka пулл риквест. Для того чтобы быть комитоцентричным в герите используют чейндж-ид, и ето хорошо, так как позволяет однозначно идентифицировать конкретный патч(коммит?) во многих ветках, и ето круто когда у тебя multi-product девелопмент(в смысле несколько основных продуктом и несколько мейнлайнов и нельзя применить up/down-merge).
topic - позволяет обьеденить несколько патчей в группу(хотя обычная линейная зависимость между комитами тоже позволяет их просматривать).

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

К слову CR ето не то же самое что и PR. CR - ето еденичное изменение, в то время как PR - ето в реальной жизни помойка где черт ногу сломит. А посля нескольких «поправок» там появляется обычно груда комитов из серии «fix type», «fix typo», «fix another typo», «fix of the fix of the fix of the fix of the typo»; и вместо того что бы поправить само изменение делаются поправки для поправок в виде очередной кучи комитов... Очень приятно потом браузить историю :) А про черипиканье или портирование на другие ветки можна вообще забыть...

Ну и из твоих претензий я вангую что рибейзится интерактивно ты не любишь, зато активно используешь down-merge из мастера в свой фиче бренч. Угадал?

А посля нескольких «поправок» там появляется обычно груда комитов из серии «fix type», «fix typo», «fix another typo», «fix of the fix of the fix of the fix of the typo»;

Кто запрещает сделать rebase сразу по мере поступления замечаний?

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

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

Это для стабильного софта с редкими релизами. Для нестабильного дев можно не заводить, а постоянно релизить сразу в мейн. Но тогда нужно принимать дополнительные меры, чтобы нестабильность софта не сказывалась на стабильности работы предприятия. Например feature-флаги и тд.

Должен отметить что мое отношение к пулл-риквестам вообще условно-негативное, я перфекционист и борец за чистоту каждого комита...

В смысле? Ты против ревью?

есть возможность стимулировать недобросовесных колег быть более аккуратными

Не понял. Стимулировать их сделать всё правильно с первой попытки? Так не бывает.

сами коментарии дублируются в секцию коментов внизу странички

Без контекста вообще.

CR - ето еденичное изменение

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

Очень приятно потом браузить историю

Опять-таки, настрой сквош коммитов, и будет тебе чистая история.

Ну и из твоих претензий я вангую что рибейзится интерактивно ты не любишь, зато активно используешь down-merge из мастера в свой фиче бренч. Угадал?

Нет, не угадал.

Мне? Никто. Я так и делаю. А вот колеги (во мнооогих компаниях из разных отраслей, джуны и матерые синьйоры) так не делают потому что могут так не делать, потому что никто в pull-requestе не смотрит на комиты, а только на total diff смотрят...

знающие люди просморят, одобрят и смерджат фаст-форвардом.

Странно, я почему-то всегда считал, что самые знающие люди — это сами разработчики.

Например feature-флаги

Это 100%.

Странно, я почему-то всегда считал, что самые знающие люди — это сами разработчики.

Разработчик разработчику рознь. Есть синьёры, есть милорды, есть молодые. Если в команде нет цветовой дифференциации штанов, может любой ревьюить, тут уже каждый коллектив сам решает свои процессы. Хотя я считаю, что иерархия нужна.

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

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

Но это да, изначально сложнее чем завести две ветки на гитхабе и обьясняет почему «менеджер проекта» (вроде так нонче называют «архитекторов») обычно получает в разы больше разработчиков ;-)

П.с. Главный профит от независимой модульности ты оценишь если:

• потребуется дать на откуп неизвестным людям интеграцию с твоим софтом своих поделок
• пойдёшь в опенсорс и проект внезапно (с) выстрелит

никто в pull-requestе не смотрит на комиты

ужасЪ!

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

В смысле? Ты против ревью?

Нет конечно. Но с практической стороны адекватно отревьювить большой кусок кода состоящий из 20 комитов почти нереально. И сквош во время мерджа всю ету кашу малашу превращает вообще в нечто неуправляемое. Смысл же Git'a в атомарности и минималистичности каждого еденичного комита. А то что творится типично в pull-requesta'ах - ад и израиль и как правило per-commit-review вообще невозможно делать.

Не понял. Стимулировать их сделать всё правильно с первой попытки?

Нет, намек на то что нужно быть более внимательным к тому что пишут ревьюверы. А то любят от джунов +1 нахвататься и все по-быстрому померджить а потом весь следующий день ревертить...

Без контекста вообще.

Пишется имя файла, и номер строки и в самом коменте как href

Нет. Патчсетов может быть хоть сотня.

Ваша руский терминология хромой. 1 change в герите == 1 commit из соответствующего бренча/хеда/коммита. Каждый change идентифицируется «уникальным» change-id, который может назодится в git-commit-message. Несколько changes могут быть обьеденены topic'ом. Каждый change может быть синтегрирован(submitted) отдельно :)