Придерживаясь правил потока git, принимая во внимание время просмотра App Store

Question

Мы уже долгое время использовали git-поток для наших проектов iOS. Однако сегодня что-то озарило меня, что означает, что мы фактически не следим за спецификацией потока git.

Когда мы начинаем окончательное тестирование выпуска, мы выпускаем версию BETA для нескольких сотен человек в нашей организации. Теперь эта BETA в основном является кандидатом на выпуск, так как никаких дополнительных ошибок не обнаружено, и в этом случае он готов к выпуску App Store. Так как 7+ дней обзора, мы всегда загружаем эту BETA в iTunes Connect и устанавливаем ее для ожидания.

Мы выпускаем эту BETA из тега на главной ветке после слияния в своей ветви освобождения. Тем не менее, git flow диктует, что главная ветвь должна отражать то, что в настоящее время находится в производстве. Теперь всегда будет время ожидания до тех пор, пока оно фактически не будет произведено (поэтому мы не сможем разбить модель потока git), но если в этой BETA обнаружены серьезные ошибки, мы удалим их из очереди просмотра, что означает, что она не собирается быть выпущенным, и теперь последняя фиксация на хозяине не отражает того, что будет в производстве.

Как вы обходите это в своем рабочем процессе?

Answer 1

Мы освобождаем эту БЕТА из тега на главной ветке после слияния в ее ветви освобождения. Однако поток git указывает, что главная ветвь должна отражать то, что в настоящее время находится в производстве.

Итак, зачем вы это делаете, если BETA в настоящее время не работает? :)

Я имею в виду, release отделения предназначено именно для отслеживания жизненного цикла кандидатов релиза в то время как они оцениваются, независимо от того, это означает, что внутреннее тестирование, бета-тестирование пользователей или, почему бы и нет, процесс обзора App Store.

Итак, я предлагаю вам держать release ветвь открытой в течение всего жизненного цикла Вашего BETA и построить оттуда версии, представленной в App Store:

• Если вы получите отказ или иметь любая проблема с ним, вы все равно можете настроить его и повторно отправить нового кандидата из той же самой ветки release.
• После того, как вы получите одобрение App Store, вы можете закрыть ветку release (которая объединяет все изменения как с master, так и с develop) и настроить ее в App Store.