Посоветуйте, где бы почитать про устоявшиеся успешные практики ветвления репозитория в условиях использования continuous integration?
Есть у нас сейчас одна ветка, master, и все изменения идут прямо туда, после код-ревью. Разработчики локально создают ветки для тех фич, над которыми они работают, а потом отправляют на код-ревью и когда код проходит ревью, система сама уже сливает все это в мастер. Но. Для того чтоб изменения были смержены, они должны пройти "верификацию" — continuous integration собирает билд и запускает на том билде полный набор тестов. Занимает все это около 5 часов. Т.е. вот прошел мой код ревью, получил я все подписи, но слить все это с мастером я физически не могу, пока билд-система не подтвердит, что билд прошел все интеграционные тесты.
Оно в этом виде более-менее работает, конечно, но сильно этот процесс меня раздражает и утомляет. Любое изменение требует 5 часов, прежде чем другие разработчики могут получить его себе. Да, про то что они могут взять изменение и слить его вручную со своим кодом — знаю, но это не то. Это как временный фикс подходит, когда нужно быстро с чем-то смержить, но не как общий подход к работе.
А если у меня вдруг есть два-три перекликающихся изменения для одной и той же части кода, то я смогу пропихнуть их в мастер не ранее чем через 10..15 часов. И это в лучшем случае — билд система часто выдает сбои по причинам кривости тестов, но это уже другой разговор. Но вот это вот все не способствует тому чтоб разработчики отправляли свои изменения мелкими порциями. Напротив — они присылают код-ревью на 30 файлов чтоб потом пропихнуть это за один заход, а не ждать пока два-три изменения пройдут верификацию.
Очевидный, казалось бы, выход — выделить ветку для разработки, куда можно будет отправить изменения с минимумом проверок (билд и юниттесты), а потом ночной билд проведет все тесты и пришлет сообщения, если что-то отвалилось. Но в этом сценарии мы получаем то, что команды разработчиков будут работать с потенциально сломанными компонентами — команд у нас несколько, разработчиков много и иногда происходят конфликтующие изменения функциональности, что приводит к долгим часам, потерянным на отладку багов, которые принесла другая команда.
Как быть? Какие подходы хорошо себя зарекомендовали?
