Нет, это все автоматизация процесса разработки. Это не CI. Это следствие того что всякие маркетологи Дженкинсов напялили себе плашку CI/CD

Ох, ладно:) Пускай это не CI, но нам нравится:)

А без CI я в изолированной ветке и другие люди в изолированной ветке. И мы интегрируемся отложенно. В момент сливания ветки после прохождения код ревью.

Хм... а мы это на CI делаем...

gitlab-ci... например... наверно он не корректно так называется

Ну если вам нравится пожалуйста. Но когда захотите увеличить эффективность команды в десятки раз, изучите все таки что такое CI/CD, TBD и DevOps.

это надо очень любить жесткий нетрадиционный секс

Ох... давай я просто куплю акции вашей команды?:)

Товарищи, давайте переходить в лс и не плодить флуд?

Ну блин... нет, это надо культура и профессионализм о котором вы же и говорили. Предполагается что разработчик делает маленькие осмысленные изменения, а не прыгает как обезьяна с гранатой пытаясь вкорячить кусок кода со StackOverflow. А секс здесь случается ТОЛЬКО когда разрабочтик влил какую то дичь. И вот прикол. Вы узнаете об это НАМНОГО РАНЬШЕ. Потому что все интегрируются несколько раз в день, а не раз в 2 недели. 🙂

у меня цепочка другая

1. на PR, который не прошел тесты, я не смотрю
2. PR, который не лезет мне в голову целиком, я не смотрю, прошу нарезать помельче
3. по PR, в котором есть изменения, которые я не понимаю, зачем сделаны, я оставляю комменты (в криминальных случаях - заворачиваю на первом таком месте)

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

То что вы описали является по сути механизмом контроля. Есть вы, а есть те кого вы контролируете и кого вы просите что-то менять и резать. Представьте что вы работаете плюс/минус с равными себе. И вот у вас хотя бы 80% покрытие тестами. Зачем вам в таком случае PR? Вы каждый коммит, который зеленый, просто игнорируете. Коммитов которые не лезут в голову у вас нет по определению. А о красных коммитах вам сообщает CI/CD система. Вы сразу можете отреагировать. Ну или не сразу, при следующем git pull (который вы делаете не реже раза в день) у вас что-то отвалится и тут то вы уж точно отреагируете.

Ладно, я на этом закончу. Заинтересовавшимся предлагаю внимательно изучить вот этот сайт и прочитать 2 книги:

- https://trunkbaseddevelopment.com/ 
- Continuous Integration: Improving Software Quality and Reducing Risk
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

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

Вот ты сейчас всех назвал незрелыми:)

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

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

Для зрелых команд работать будет все и GitFlow с бранчами и ревью, и CI/CD.
Просто второй чаще будет в десятки раз эффективнее. Но команде может быть это и не нужно.
а бизнес об этом даже не подозревает. И тогда все норм 🙂

Code review не нужен когда ты уверен что все задачи которые пройдут через code review не дадут никакого результата... если же все задачи на code review не показывают ничего интересного - значит либо code review не делается либо команда идеально сбалансирована... и такого просто не бывает:)

Эффективность за которой все гонятся...

http://lib.tkk.fi/Diss/2009/isbn9789512298570/article5.pdf - вот почитайте. Потом почитайте еще автоматизированные тесты какой процент ошибок назодят и какого типа. Потом просто подумайте и сопоставьте цифры.