Народ, поделитесь информацией, есть ли в вашей конторе какая-нить политика-админство гитования.
Или пушат и мержат все кому не лень без всякой политики?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>Народ, поделитесь информацией, есть ли в вашей конторе какая-нить политика-админство гитования. LVV>Или пушат и мержат все кому не лень без всякой политики?
В качестве git-сервера используем MS AzureDevops.
Там права (branch permissions) и политики (branch policies) на ветки определяются на базе иерархических имен (Hierarchical branch folders c wildcards).
Через права можно ограничить действия на ветке, например чтение/запись/перезапись истории и пр.
Через политики — настроить gated check-in — через PR c различными предусловиями (сборка build`а, прохождение автотестов, review), а также ограничить способы merge (всего 4 варианта) и пр.
Ветки делим на релизные (прошлые и текущие релизы) и feature (для разработки отдельных feature одной или несколькими командами). На них, как правило, запрещена перезапись истории, настроены политики по PR (автотесты и review на базе путей в репозитории). Иногда могут быть некоторые ограничения по типу merge.
И персональные (личные) ветки — там владелец ветки (разработчик) настраивает всё по своему усмотрению.
Тип ветки, назначение и принадлежность (личных веток) определяется на базе иерхической системы имен.
Есть еще политики на запуск build`ов — какие на каких ветках можно запускать. И др. workflow на разные случаи жизни .
LVV>>Народ, поделитесь информацией, есть ли в вашей конторе какая-нить политика-админство гитования. LVV>>Или пушат и мержат все кому не лень без всякой политики?
С правами — это понятно, это все можно настроить т п.
А есть чел, которые за все это отвечает?
И много ли человек в проекте одновременно работает ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>>Или пушат и мержат все кому не лень без всякой политики? LVV>С правами — это понятно, это все можно настроить т п. LVV>А есть чел, которые за все это отвечает?
Да есть выделенное подразделение (пара человек), которое занимается source control, build`ами и AzureDevops в целом.
Но они не занимаются рутинными слияниями и т.п. В зависимости от направления merge этим занимаются тимлиды лично, либо кто-то из них включается в required reviewers PR, а PR формирует обычный разработчик.
У тимлидов есть повышенные права, либо права им выдаются временно для определенных действий согласно документированному workflow.
LVV>И много ли человек в проекте одновременно работает ?
Над одной feature работает 1-3 команды по 4-8 человек. Feature в разработке обычно несколько и ещё bugfix, поэтому общее число людей, работающих с репозиторием, больше.
По коду пересечений между командами как правило нет, но, т.к. Git в отличие от других VCS не предполагает выборочного merge (если только не использовать cherry pick), то конфликты в "чужом" коде приходится разрешать совместными усилиями
Здравствуйте, LaptevVV, Вы писали:
LVV>Народ, поделитесь информацией, есть ли в вашей конторе какая-нить политика-админство гитования. LVV>Или пушат и мержат все кому не лень без всякой политики?
LVV>>А кто нибудь за этим следит? LVV>>Или это записано в каком-то доке?
N>Нет и нет, просто есть культура, которая распространяется сама по себе.
Ну раз Вам всё просто и понятно, то можете прокомментировать ситуацию описанную здесь.
Так ли опасна ситуация, как пишет автор статьи, и почему для решения не достаточно "культуры", а нужен pre-receive hook.
Здравствуйте, m2user, Вы писали:
M>Ну раз Вам всё просто и понятно, то можете прокомментировать ситуацию описанную здесь. M>Так ли опасна ситуация, как пишет автор статьи, и почему для решения не достаточно "культуры", а нужен pre-receive hook.
Зависит от конкретной команды. У нас можно в течение 5-10 минут собраться и устно всё порешать. А ещё более менее известно, кто и за какой кусок кода отвечает.
Здравствуйте, LaptevVV, Вы писали:
LVV>Народ, поделитесь информацией, есть ли в вашей конторе какая-нить политика-админство гитования. LVV>Или пушат и мержат все кому не лень без всякой политики?
develop, master, release/*, hotfix/* — комиты только через mr, с автотестами, в остальных ветках можно делать кто что хочет
Здравствуйте, LaptevVV, Вы писали:
LVV>С правами — это понятно, это все можно настроить т п. LVV>А есть чел, которые за все это отвечает? LVV>И много ли человек в проекте одновременно работает ?
Мы тоже используем Azure. В разных репозиториях разные настройки. Наиболее строгие в корневых С++ библиотеках и продуктах, отвечает за них тех.лид. Человек 20 туда коммитит.
Есть мастер, есть релизы бранчи. Все остальное short-lived branches, включая feature, hotfix, bugfix etc. Создаются и уничтожаются по факту мержа либо в мастер либо в релиз. hotfix/bugfix могут мержится в несколько мест (см. черрипикинг), если проблема в релиз бранче — но самое простое и чистое решение мержить фиксы в релиз и перед отдачей релиза/по мере необходимости мержить весь релиз в мастер (естественно, для этого есть какое то opportunity window, которое со временем закрывается).
Чем больше бранчей, тем больше проблем, количество параллельно поддерживаемых бранчей — главный источник сложности, зачем их плодить? За 10 лет я не видел нужды в develop бранче/где бы это использовалось.
по поводу политик — мне нравится как сделано в GitLab — protected branches, защищенные бранчи — в них нельзя мержить напрямую (или можно, но не всем), обычно это мастер, иногда релизы. Соответственно, для изменения кода необходимо создавать бранч и проходить через процедуру ревью и проверок перед мержем (например запуск тестов и код кавераджа). На практике этого хватает, усложнить, конечно, можно, но зачем?
релиз бранчи формируются и поддерживаются релиз инженером или равноправным лицом, это немного другая работа, нежели непосредственно разработка, но все решается в рамках скрума или для частных случаев митингами.
Здравствуйте, LaptevVV, Вы писали:
LVV>Народ, поделитесь информацией, есть ли в вашей конторе какая-нить политика-админство гитования. LVV>Или пушат и мержат все кому не лень без всякой политики?
Мне нравится схема, которую показал как-то коллега и она прижилась. Названия не знаю, возможно кто-то подскажет.
Используется две основных ветки: develop/release.
develop развернут на staging, в нем тестируются таски/фичи. release в нем всегда протестированный код (развернут на другом staging, но это по желанию).
В отличии от gitflow, develop в release не вливается никогда.
v QA/fix v done
develop ---------------------------------------
/ /
TASK-01-login-users ----------------------------
/ \
release ---------------------------------------
^ develop/review ^ ready to deploy
Жизненный цикл таски — стартуем ветку от release, вливаем в develop, тестируем, после апрува QA эту же ветку таски вливаем в бранч.
Процесс чуть сложнее gitflow, но гарантирует то, что в release в любой момент лежит только протестированный код и в нем нет ни одной сырой таски. Очень удобно.
Здравствуйте, Ziaw, Вы писали:
Z> Жизненный цикл таски — стартуем ветку от release, вливаем в develop, тестируем, после апрува QA эту же ветку таски вливаем в бранч.
Плохо. Будут мучения с резолвингом конфликтов.
Мерж таск-ветки в релиз и в девелоп происходят в разное время. Более менее работоспособно только для маленьких проектов с парой независимых тасков. На большом проекте у тебя будет много таск-веток, некоторые с зависимостями друг от друга, которые вливаются в develop и релиз в разные моменты времени.
Это приведёт к конфликтам и они могут разрешаться немного по-разному. В итоге в release окажется код, который немного отличается от того, что было в develop. Т.е. тестироваться будет не тот код, который релизится. Опасно.
Z>> Жизненный цикл таски — стартуем ветку от release, вливаем в develop, тестируем, после апрува QA эту же ветку таски вливаем в бранч. ·>Плохо. Будут мучения с резолвингом конфликтов. ·>Мерж таск-ветки в релиз и в девелоп происходят в разное время. Более менее работоспособно только для маленьких проектов с парой независимых тасков. На большом проекте у тебя будет много таск-веток, некоторые с зависимостями друг от друга, которые вливаются в develop и релиз в разные моменты времени.
Полагаю, что раз выбран такой подход, то таски у них не пересекаются по коду (такое может быть и на больших проектах). А если так случится, что пересекаются, то сделают промежуточную ветку task01+task02.
·>Т.е. тестироваться будет не тот код, который релизится. Опасно.
А это и так будет, потому что фичи могли в develop тестироваться вместе, а в release попасть в разное время. Или вообще фичу могут по результатам тестирования отложить до лучших времен.
Очевидно, что все это будет надежно, только если фичи независимы.
Здравствуйте, m2user, Вы писали:
m> Z>> Жизненный цикл таски — стартуем ветку от release, вливаем в develop, тестируем, после апрува QA эту же ветку таски вливаем в бранч. m> ·>Плохо. Будут мучения с резолвингом конфликтов. m> ·>Мерж таск-ветки в релиз и в девелоп происходят в разное время. Более менее работоспособно только для маленьких проектов с парой независимых тасков. На большом проекте у тебя будет много таск-веток, некоторые с зависимостями друг от друга, которые вливаются в develop и релиз в разные моменты времени. m> Полагаю, что раз выбран такой подход, то таски у них не пересекаются по коду (такое может быть и на больших проектах).
Вполне верю. Просто он это описал как альтернативу стандартного flow. Нет уж, стандартный flow вполне универсален, а предложенное выше работает только в определённых тепличных условиях.
m>А если так случится, что пересекаются, то сделают промежуточную ветку task01+task02.
Угу, много чего интересного может случиться (где например хотфиксы в его схеме?), и появятся новые магические ветки. И в итоге у них получится кривоватое подмножество flow.
m> ·>Т.е. тестироваться будет не тот код, который релизится. Опасно. m> А это и так будет, потому что фичи могли в develop тестироваться вместе, а в release попасть в разное время. Или вообще фичу могут по результатам тестирования отложить до лучших времен. m> Очевидно, что все это будет надежно, только если фичи независимы.
Угу. Притом независимость — нетривиальное свойство, т.е. без серьёзного доказательства и исследования определить независимость фич невозможно.
.
