Модель ветвления TFS для поддержки длительного цикла QA (системного тестирования) - PullRequest
Новая
       11

Модель ветвления TFS для поддержки длительного цикла QA (системного тестирования)

2 голосов
/ 30 июля 2009

Допустим, у вас есть приложение. Это приложение должно быть проверено и развернуто для производства. Существуют некоторые ограничения на жизненный цикл приложения.

  1. В производстве будет существовать только одна версия приложения.
  2. После развертывания в производство, возможно, потребуется разработка необходимых исправлений. Оперативное исправление предназначено для устранения специфического дефекта высокой степени опасности и не предусматривает новых функций. Изменение кода исправления должно быть обратно интегрировано в другие ветви.
  3. Прежде чем перейти к производству для выпуска новой функции, он должен пройти цикл QA.
  4. После выпуска в QA тестирование приложения занимает значительное время. На первом цикле QA, если QA открывает 20 дефектов, их необходимо исправить в следующем выпуске для QA без каких-либо дополнительных функций для тестирования. Если команда QA вновь откроет, скажем, 10 дефектов, то при следующем выпуске QA они захотят исправить только эти 10 дефектов. Никаких других дефектов или каких-либо новых функций. Следующий выпуск функции может произойти только после того, как число дефектов станет равным 0 (или некоторые дефекты будут решены как не исправленные или улучшенные и т. Д.).
  5. Поскольку цикл QA требует времени, в течение этого времени развитие не может быть остановлено. Необходимо продолжить разработку новых функций для следующего выпуска.

Как бы вы настроили модель ветвления TFS.

1 Ответ

3 голосов
/ 30 июля 2009

Звучит так, будто вы идеальный кандидат на "стандартную" стратегию из руководства по слиянию и слиянию TFS: http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

По сути, это берет вашу базовую модель Dev <-> Main <-> Release, а затем добавляет еще один слой косвенности. Оперативные исправления получают свою собственную ветвь на стороне релиза иерархии, так что их разработка + тестирование не нарушает обычный цикл QA, происходящий в Main, и не загрязняет святость Release. Вы можете увидеть наглядную иллюстрацию на странице 7 в PDF.

Есть ли у вас железное требование, чтобы ветви (ии) Release представляли точный моментальный снимок производства (т. Е. Существует связь 1: 1 между проверками для Release и развертываний и / или отдельной веткой Release, созданной для развертывания)? Если нет, то вам может даже не понадобиться ветка исправлений - делайте исправления непосредственно в Release. Это описано в «Основной» стратегии ранее в документе.

В любом случае, обязательно прочитайте весь комплект документов. Это не долго, но извлекает много результатов из реальных реализаций. («Рейнджеры VSTS» в основном состоят из MVP и других местных консультантов)

Чтобы получить более теоретический взгляд на стратегии развития команды и их реализацию в TFS, ознакомьтесь с документами из группы «Шаблоны и практики»: http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html

...