Что делать, если функция, тестируемая в вашей среде QA, откладывается?

Question

Наш СКМ - это Subversion.И я не знаю, как справиться с этим сценарием.

Допустим, у меня есть следующие ветви:

• РАЗРАБОТКА (магистраль)
• QA
• ПРОИЗВОДСТВО

В багажнике у нас есть следующие функции (F):

• F1
• F2
• F3

F1 и F2 готовы к тестированию в среде QA, поэтому изменения, соответствующие этим функциям, объединяются в ветвь QA.QA:

• F1
• F2

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

Это означало бы, что мне нужно будет объединить только изменения, соответствующие F1, в ветку PRODUCTION, но это также будет означать, что этот новый результат не будет таким же, как те, кто уже тестировал QA, потому чтоПРОИЗВОДСТВЕННАЯ ветвь будет иметь только требование F1.Я не могу гарантировать, что он будет работать, и мне кажется, что этот новый объединенный код поступает в производство без всякого тестирования.

Это может привести к различным проблемам, например: - Что, если существует какая-то зависимость междуF1 и F2 (они не должны выпускаться самостоятельно) - вы никогда не будете знать наверняка, будет ли работать новый код, потому что не было среды для тестирования этого нового объединенного кода.

Как бы вырешить это?

Спасибо и простите за мой английский.

Answer 1

Вы можете порекомендовать быстрый цикл сборки в ветке QA.Откатить нежелательные изменения (либо выполнить слияние с более ранней версией в ветви QA, либо взять новую ветку для QA и объединить только изменения F1 в новую ветвь QA) - в основном, рекомендовать быстрый цикл тестирования сборки и исправности докод выпущен в производство.Выделите риски, связанные с выпуском непроверенного кода в сценарий LIVE.

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

Гудлак.

Answer 2

В целом, использование отдельных веток для РАЗРАБОТКИ, ОТКРЫТИЯ и ПРОИЗВОДСТВА будет непростым в управлении, именно из-за ситуаций, подобных описанной вами.По сути, поскольку вы не можете верить, что ветви QA и PRODUCTION идентичны, вам придется запустить весь процесс тестирования в ветви PRODUCTION после объединения из ветви QA.Так что же хорошего в том, чтобы иметь отдельные ветви?

В Subversion Book есть статья о Общих шаблонах ветвления , в которой предлагается использовать функциональные ветви (которые QA может тестировать напрямую) и объединять в магистралькогда готов к выпуску;Еще один вариант, который он предлагает, - это транк, который разветвляется на ветки релиза, где ошибки могут быть исправлены до или после релиза.

Одна вещь, которую вы можете сделать, чтобы лучше контролировать, какие функции готовы к выпуску, этоиспользовать функциональные флаги - это позволяет QA параллельно тестировать F1 и F2 и выпускать все, что будет готово.

Answer 3

Но что, если менеджеры захотят выпустить F1, потому что QA уже завершила тестирование на требование F1, но это не относится к F2?

Это прерогатива менеджеров. Они могут решить выпустить только F1.

Вы несете ответственность за то, чтобы сказать, что F1 не был должным образом протестирован в среде обеспечения качества. Вы привели причины в своем вопросе.

Это означало бы, что мне нужно будет объединить только изменения, соответствующие F1, в ветку PRODUCTION, но это также будет означать, что этот новый результат не будет таким же, как те, кто уже тестировал QA, потому что в ветви PRODUCTION будет только F1 требование. Я не могу гарантировать, что он будет работать, и мне кажется, что этот новый объединенный код поступает в производство без всякого тестирования.

Вы правы. Опять же, ваша обязанность состоит в том, чтобы сказать, что F1 не был протестирован один в среде обеспечения качества.