Mercurial - предоставление изолированных функций для тестирования и жизни - PullRequest
Новая
       24

Mercurial - предоставление изолированных функций для тестирования и жизни

3 голосов
/ 14 марта 2011

Мы собираемся обменяться на Mercurial.В нашем плане отсутствует элемент управления ветвлением / слиянием сборки с Test Box (и LiveBox), чтобы изолированные функции можно было смешать со StableRelease и встроить в TestBox.

Например, кажется, чтоПреимущественное использование должно иметь

  • DefaultStableBanch
    • TestBanch
      • FeatureABranch
      • FeatureBranch

Разработка для FeatureA и FeatureB будет происходить одновременно.Похоже, что преимущественное использование состоит в том, чтобы клонировать репозитории с ветвями для вышеперечисленного.

Сценарий 1: Если мы собираемся тестировать, мы объединяем LiveCode + FeatureA + FeatureB.Если все пойдет хорошо, мы можем объединить наборы изменений в ветке по умолчанию с веткой DefaultStable и собрать в LiveBox с FeatureA и FeatureB.работа сделана.

Сценарий 2: Если мы собираемся для тестирования, мы объединяем LiveCode + FeatureA + FeatureB, и QA показывает, что есть проблема с FeatureB.Мы больше не хотим создавать FeatureB.Мы хотим прогрессировать FeatureA.Мы хотим провести повторное тестирование с FeatureA самостоятельно и позволить QA это пройти.Затем добавьте это в Live и, следовательно, к гибкости бизнеса.

Вопросы: если FeatureB не сможет выполнить QA, нам нужно вынуть узлы ревизий FeatureB из тестовой ветви, снова собрать в TesBox, а затем, надеюсь, объединить восходящую ветку с веткой DefaultStable иLiveBox.
Каков наилучший способ удаления узлов наборов изменений FeatureB из TestBranch, поскольку 1. нам нужно больше dev для FeatureB, а набор узлов FeatureB не закончен.2. Нам нужно изолировать DefaultStable + FeatureABranch и построить его для тестирования

Как другие люди управляют этим?

Ответы [ 2 ]

2 голосов
/ 14 марта 2011

Существует множество отличных рецензий рабочих процессов Mercurial, в том числе:

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

Удар по вашему конкретному вопросу, если комбинация LiveCode + FeatureA + FeatureB не проходит тестирование, лучший способ справиться с этим - просто восстановить FeatureB и затем объединить эти изменения вFeatureA + Feature B. Тем не менее, прежде чем перейти к этому этапу, неплохо бы, чтобы QA ударил LiveCode + FeatureA и LiveCode + FeatureB по отдельности, для них немного больше работы (больше целей тестирования), но каждая отдельная функция помогает найтипричина дефекта быстрее.

Как только LiveCode + FeatureA и LiveCode + FeatureB проходят QA, затем вы объединяете их в LiveCode + FeatureA + FeatureB и, если это все еще проходит тесты, объедините все это в DefaultStable.Не нужно удалять FeatureB из LiveCode + FeatureA + FeatureB, потому что вы всегда можете просто создать новый клон LiveCode и объединить только FeatureA, если хотите.

Вот отличная рецензия процесса контроля качества / выпуска на основе Mercurial (Kiln):

http://blog.bitquabit.com/2011/03/10/when-things-go-well/

1 голос
/ 14 марта 2011

Создание FeatureA и FeatureB в ветвях клонов функций из стабильного.Тест - это просто временная область для работы QA / Test, поэтому я бы с первого дня отнесся к ней как к выбору.

Когда FeatureA и FeatureB достаточно развиты, создайте клон одного из них и перетащите другой в QA / Test.Выполните сборку для QA, и, когда они предоставят обратную связь, внесите соответствующие изменения в FeatureB.

Если FeatureA приемлемо для продвижения, перетащите его в / переведите в стабильный и объедините в стабильный.

Это яснее, чем мой оригинальный пост?

...