Блог

Мы работаем над системой, в которой мы собираемся внести много изменений в течение следующего года или около того. Мы используем Azure DevOps с TFVC. Наш план заключается в разработке, внутреннем тестировании, выпуске в промежуточную среду для внутреннего тестирования клиента, а затем выпуске в оперативную среду, как только ошибки будут устранены, но мы хотим делать это довольно небольшими итерациями, поэтому мы не выпускаем сразу большие изменения, и мы можем получить раннюю обратную связь об изменениях, чтобы убедиться, что мы на правильном пути и не завалены множеством проблем, которые нужно исправить после большого обновления.

Проблема, которая меня беспокоит, заключается в том, что после выпуска в среду тестирования клиенту потребуется время для ее тестирования, и в течение этого времени мы будем работать над другими улучшениями / исправлениями ошибок. Если клиент просто говорит, что все в порядке, я могу использовать VS, чтобы получить конкретную версию на момент выпуска промежуточной версии, а затем собрать и выпустить ее для использования, но если возникнут какие-либо проблемы, и нам нужно их исправить, нам в конечном итоге придется заставить клиента протестировать все новые материалы, над которыми мы работали, и мы можем оказаться в процессе внесения больших изменений, которые нецелесообразно выпускать для промежуточной версии.

Я просмотрел ветви TFS, но они, похоже, путают пути и затрудняют настройку и работу, и я чувствую, что они на самом деле не для такой ситуации.

Как люди обычно решают эту проблему?

(Я ценю, что многие люди будут утверждать, что Git — лучшая система управления версиями, но я конкретно спрашиваю, как это сделать с помощью TFVC)

Ветви в TFVC далеко не легкие и могут затруднять переключение между ветвями локально.

Трудно избежать изменения локальных путей при переключении, это можно сделать, изменив определение рабочей области, переназначив папки и принудительно установив последнюю версию.

Здесь можно использовать еще один вариант git tfs , он позволит вам использовать TFVC на сервере, но Git локально и получать локальные преимущества (включая несколько локальных филиалов и возможность переключения между ними на месте).

Метод работы со средами и утверждениями во время разработки заключается в создании ветвей уровня продвижения. Одна ветвь для активной разработки, ответвление от этой ветви для следующей среды (тест), а затем следующая (принятие?) весь путь до вас доходит до производства.

  Development
 — Test
       — Acceptance
             — Production
  

Каждый раз, когда разработка достаточно стабилизируется, объединяйте код для тестирования. Любые проблемы можно устранить либо непосредственно при тестировании, либо исправив их в процессе разработки, а затем выбрав вишню.

Чем больше расстояние между разработкой и производством, тем сложнее будет синхронизировать ветви.

Альтернативой является использование ветвей выпуска, в основном немного сворачивающих вышеупомянутую структуру:

  Main
 — Release 1
 — Release 2
  

Активная разработка происходит в Main, код объединяется и исправляется в ветвях выпуска. Все изменения, внесенные в ветку выпуска, также должны быть объединены обратно.

Есть лучшее решение

Вместо того, чтобы пытаться быть более продуктивным, работая над новыми функциями, можете ли вы помочь клиенту быстрее протестировать потенциальные версии? В этом случае вам не нужно будет слишком долго ждать завершения тестирования, вы сможете быстро исправить ошибки, а затем переключить внимание на новые разработки. Это предотвратит всевозможные проблемы со слиянием, повторное появление ошибок в коде, который не был правильно объединен с main и т.д.