зачем?

что зачем?

зачем интегрироваться часто?

зачем лайфцикл PR сокращать до одного дня или меньше?

один PR = одна ветка?

если PR висел полдня, но ветку делали пару дней?

полностью от момента создания брэнча до вливания его в мастер менее суток

ну может 2 дня... но это типа беспредел уже

ага, а зачем?

что бы интегрироваться постоянно)

оставим пока вопрос "зачем" на четверг ;)

но если коротко - уменьшение рисков так как частая интеграция = интеграция маленькими кусками = заставляет дробить работу = меньше рисков/багов поскольку ты фокусируешься на задаче лучше

что бы интегрироваться постоянно)

что значит "интегрироваться постоянно" и как это связано с временем жизни PR?

что значит "интегрироваться постоянно" и как это связано с временем жизни PR?

ну вот я не могу скоррелировать идею фича брэнчей и CI

(в последний раз я забил и ввел у себя на проекте trunk-based dev)

мне кажется, ты в крайности ударяешься

мне кажется, ты в крайности ударяешься

мне кажется нет)

я не понимаю, в чем проблема и несоответствие, чтобы его пытаться решить

просто есть такие задачи, которые ну никак не решить за день

и более того

я не понимаю, в чем проблема и несоответствие, чтобы его пытаться решить

потому я спросил есть ли тут кто у кого реально есть CI (а лучше сразу CD)

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

просто есть такие задачи, которые ну никак не решить за день

и есть подходы которые позволяют тебе их делать в мастере

чтобы всем объяснили? :)

чтобы всем объяснили? :)

меня не интересует вопрос "зачем" - меня интересуют реальные ситуации когда у людей настойщий CI и они делают PR (для код ревью). Ибо пока-что я прихожу только к тому что с PR это намного сложнее чем с trunk-based dev

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

для API во всяком случае от PR я вообще профита не вижу...

я глянул "что есть trunk-based dev" и в формулировке там вполне себе стоит PR как условие мерджа (необязательное, правда)

ты имеешь ввиду мелкие ветки и быстрый мердж в транк?

я глянул "что есть trunk-based dev" и в формулировке там вполне себе стоит PR как условие мерджа (необязательное, правда)

short-living feature branches то есть ветки которые существуют ну может день-два перед вмердживанием.

альтернатива - херачить сразу в мастер для команд которые не умеют делать short-living фича брэнчи

и есть подходы которые позволяют тебе их делать в мастере

скажи, как гуглить по этой штуке

https://trunkbaseddevelopment.com

тю, я тут и был

там два популярных - фича тоглы и branch by abstraction (крутая штука)

фича тоглы лично я пока не юзал, но знаю людей которые активно юзают и довольны

более того с ними работал но поскольку пилил API и все тоглы были на уровне UI...

хотя build-time тоглы у меня были тоже... так что... может можно говорить что юзал

bba почитал и понял - штука логичная, но имеет смысл в относительно крупных командах/проектах

там, где есть много связности

ага, фичетоглы тоже из той же оперы, уловил

штука прикольная но в build-time версии проект становится зависимым от внешних штук... чуть повышается уровень опасности сделать буллщит

bba почитал и понял - штука логичная, но имеет смысл в относительно крупных командах/проектах

почему же только в относительно крупных?

бо мне не надо хД

штука прикольная но в build-time версии проект становится зависимым от внешних штук... чуть повышается уровень опасности сделать буллщит

ты можешь не юзать внешние штуки а просто иметь конфиг)

на самом деле я не вижу большого профита от быстродохнущих фиче-бранчей в таком сценарии

bba вроде и ок но это выглядит как "костыль, чтобы ветки долго не жили"

на самом деле я не вижу большого профита от быстродохнущих фиче-бранчей в таком сценарии

альтернатива - херачить сразу в мастер))

удобненько

bba вроде и ок но это выглядит как "костыль, чтобы ветки долго не жили"

это не кастыль - это способ уменьшить риски (путем уменьшения изменений).

с другой стороны сначала поставили ограничение - потом его обходим ценой большего колва кода и (!) потенциально большего количества мест для ошибки

тут да, билд сервер поможет

но он и с просто мерджем старой фичеветки от такого спасет а вообще я мечтаю о branch-based билдах автоматических

с другой стороны сначала поставили ограничение - потом его обходим ценой большего колва кода и (!) потенциально большего количества мест для ошибки

количество мест для ошибки не особо то и увеличивается (если не уменьшается) на самом деле

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

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

но я еще не определился с тем когда что лучше юзать

в той ситуации когда я применял trunk-based - мне нужно было скоординировать довольно крупные изменения в системе между командой из 10-ти человек (+ человек 20 кто косвенно работал с тем что мы делали).

и это было максимально эффективно

а сейчас у меня ситуация при которой "координировать" надо человека 3 которые не сказать что часто пересекаются

там да фичеветки, вероятно, лучше подойдут для компактных изменений

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

мне их контролить не надо)

в плане жесткие или нет проверки в PR

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

с trunk based у меня там парное программирование вместо ревью было.... немножко

по идее bba тоже сюда ляжет норм еще и за счет того, что точек контроля будет больше + early check в плане архитектуры/размещения кода и тд

Нужен совет.

Есть сущность, скажем, Vacancy. Есть метод Vacancy::up(UserInterface $user). Хочу запилить проверку на то, может ли текущий пользователь поднять эту вакансию. А может только если есть соответствующие права. Если он автор или модератор/админ.

Правильно ли будет добавить в этот метод (и в похожие ему) второй аргумент как-то так: public function up(WebUserInterface $user, AccessDecisionManagerInterface $access) { if (!$access->isGranted($user, ['edit_vacancy’], $this)) { throw new SomeException(); } <…> }

Если что, это не Symfony, просто немножко похоже)

почему не ~так public function up (WebUserInterface $user){ $user->can/garanted/access ??? { ... } }

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

почему не ~так public function up (WebUserInterface $user){ $user->can/garanted/access ??? { ... } }

Думаю, это более интересный вариант. Надо попробовать.

но он и с просто мерджем старой фичеветки от такого спасет а вообще я мечтаю о branch-based билдах автоматических

Никто не мешает запилить автоматический билд для всех фича-веток, кроме каких-нибудь специальных имён вроде *-no-build :) Длина фича-веток, вообще говоря, зависит от сложности задачи, и тут сходу не всегда можно хорошо угадать, если постановка расплывчатая. Бывает, что фича может внезапно выливаться в две недели и более. В этом случае автор фича-ветки (а у нас фича-ветки считаются персональными) сам периодически делает rebase и следит за интеграцией. В идеале перед выполнением PR фича-ветка должна расти прямо из trunk'а и не вызывать конфликтов при мерже в голову.

Lmao, nice design

omfg my eyes

@fes0r дайте админку - просто чтобы спам удалять

@fes0r дайте админку - просто чтобы спам удалять

достаточно пинговать админов)

вообще надо бы подумать о том что бы автоматизировать процесс...

достаточно пинговать админов)

k

А кто такой Антон?) Ни разу не видал его сообщений

пишет иногда, и не только тут

А кто такой Антон?) Ни разу не видал его сообщений

напиши чё-нить гадкое про ddd, или про es/cqrs, сработает триггер у него)

?