Pull to refresh

Comments 4

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


В смысле? А почему «новый разработчик» имеет права на слияние в основную ветку?
Не хватает более технических деталей и, например, графа пайплайна. Что значит «мастер отстает от продакшна»? Если есть Continuous Delivery\Rolling releases, то продакшн == мастер же (обычно?).

Если нет, то в чем была проблема с обычными ПР? Девелопер создает ПР, запускается CI, получаются аппрувы — все зеленое — вливаем. Или речь о неком подобии Marge Bot, чтобы переложить на робота бесконечные ребейзы\попытки угнаться за постоянно уходящим вперед мастером?
Спросил тот же вопрос в коммантах к оригинальной статье, автор ответил.

n theory, if everything passes, that is true. But as soon as something gets merged to master and «breaks the build», then suddenly we won't be able to deploy anymore. With the rate of merges that we get, this quickly turns into a large backlog. When the blockage gets resolved, the next deploy becomes substantially more risky because of the volume of changes that have to go out at once now.

I mean in the case without the merge queue — this isn't a problem with the solution we created that allows us to run CI before merge. Without this tool, developers will have to rebase their branches and run CI. With the volume of changes we get, master would change so frequently that by the time CI completes, the branch is already out of date.


Как я понял ответ — именно что сделали своего мерж-бота, чтобы избежать бесконечных ребейзов и группировать ПР перед мержем. Ну окей.
1000 разработчиков… Меня очень интересует, чем их можно занять в компании, занимающейся только одним приложением?
Sign up to leave a comment.

Articles