Как справиться с развертыванием w / Git в среде, где ветвь интеграции не всегда готова к работе

Question

Итак, я понимаю, что это загадочное название, поэтому позвольте мне уточнить. У меня есть среда с 15 разработчиками, и в любой момент до 5 из нас могут работать над одним и тем же набором кода. Это веб-приложение на PHP, в котором много унаследованного / процедурного кода, поэтому мы часто редактируем одни и те же файлы, и некоторые из наших изменений могут быть весьма серьезными.

В результате интеграция несколько усложняется, но, что еще важнее, иногда разрабатывается функция, которая проходит несколько этапов контроля качества и анализа по маркетингу, в то время как другие, более мелкие функции необходимо развернуть.

В настоящее время, чтобы избежать застревания в QA / интеграции, ветка integration является своего рода тупиковой ветвью, и когда что-то действительно готово, она объединяется непосредственно из своей функциональной ветви в master, master выдвигается для развертывания на действующем сайте.

Я пытаюсь создать более плавный рабочий процесс, в котором функции объединяются в QA, а затем QA сливается в master в качестве развертывания, но мне нужно решить вопрос о функциях, которые не готовы к работе, будучи смешанными с меньшими функциями на integration. Я готов исследовать некоторые альтернативные способы обработки более длительных функций, а не их слияния в ветку integration, но я сам попал в стену.

Answer 1

Вам необходимо принять идею "Кандидата на выпуск".

Я объяснил процесс для этого здесь: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Дайте мне знать, если у вас есть какие-либо вопросыоб этом рабочем процессе.

Answer 2

Дело в том, что с N функциями у вас есть N + (N выберите 2) + (N выберите 3) + (N выберите 4) + ... + 1 различных комбинаций.

По-английски это «о Боже, как много комбинаций».

Таким образом, вы не создаете ветви интеграции для каждого возможного подмножества своих функций: вы тестируете только те комбинации, которые вам небезразличны о.Если что-то не готово к прайм-тайму само по себе, оно никак не готово к прайм-тайму в тандеме с другими функциями.Как только все функции, входящие в конкретный выпуск, готовы, вы создаете интеграционную ветку со всеми ними вместе, проверяете ее и затем отправляете.

Выможет проводить тестирование с «предварительной интеграцией», чтобы посмотреть, насколько хорошо 2, 3, 4 или около того функции играют друг с другом, но эти ветви не являются «авторитетными» по отношению к QA: потому что у вас нет окончательного набора всегоэто будет отправлено туда, вы не можете назвать все, что делаете, действительно QA.

Таким образом, у вас нет ветви "интеграции" - каждая ветка интеграции для одного завершено партия вещей, которые готовы к обеспечению качества.Если что-то пробивается туда, что нехорошо, вся ветка потерпит неудачу в QA, так что ничто не пробьется из плохой ветки в развернутое состояние - это означает, что вам никогда не придется говорить «этот бит хорош, этот битплохо, потяните это, оставьте это " после процесса QA: это создаст по существу непроверенную комбинацию функций.