Это не тот вопрос, по которому у меня нет идей, но вместо этого я хотел бы представить модель и посмотреть, будет ли она одобрена, или у кого-нибудь могут возникнуть проблемы с ней или есть лучшие предложения. Говорят, что лучше тщательно выбирать модель ветвления, чтобы избежать головной боли в будущем.
Таким образом, у нас есть внутреннее приложение только с одной версией (последней), выпущенной для клиентов, и в основном есть 2 вида деятельности по разработке: основная деятельность работает над следующим выпуском и обычно включает новые функции и корректирующие исправления, и это запланировано, а второе, которое не запланировано, связано с обслуживанием и включает исправления текущей версии в производстве.
После долгих исследований мы решили использовать главную ветку, из которой мы разветвляем 2 дочерние ветки: Разработка и Техническое обслуживание (или Исправление). Как показано в руководстве, ежедневная разработка будет происходить в ветке Разработка, откуда мы выполняем обратную интеграцию (RI) каждый раз, когда у нас есть функции, готовые к следующему выпуску. Прямо перед релизом обратная интеграция будет остановлена, а код будет стабилизирован в ветке Main. После выпуска из Main будет произведена прямая интеграция (FI) из Main в Разработку и Техническое обслуживание.
Любое исправление будет происходить только в Maintenance, и в зависимости от исправления (например, если мы хотим сохранить его в кодовой базе) мы выполним RI в Main, а оттуда FI в Развитие.
Сейчас все выглядит нормально, по крайней мере на бумаге, поэтому хотелось бы услышать мнение других об этой модели.
Например, мы бы также рассмотрели возможность создания еще одной ветки, Release, в которой стабилизация кода происходит перед выпуском в рабочую среду (вместо работы непосредственно в Main), и, конечно же, мы выпустит отсюда в рабочую среду и выполнит RI в Main, а затем FI в Development и Maintenance, но мы не уверены, что это принесет какую-то пользу или только усложнит?
И если предположить, что в Разработке будут функции, которые не будут готовы или нежелательны для следующего выпуска, это означает, что нам придется сделать некоторый «выбор вишен» из наборов изменений, связанных с желаемыми. функции, но это не слишком хорошо в соответствии с документами. Какие-либо предложения?
Опять же, я знаю, что это не простой, прямой вопрос, а скорее открытый, но я все же надеюсь услышать кого-нибудь с подобным опытом. Заранее спасибо за внимание.
