Обзор кода нескольких проверок в TFS 2012

Я пытаюсь установить инструмент проверки кода TFS 2012 в рабочий процесс.

Текущий рабочий процесс выглядит следующим образом:

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

Я пытаюсь реализовать эту процедуру в TFS 2012. Основная проблема заключается в том, что я не могу понять, как создать обзор на основе нескольких проверок. Неудобно создавать запрос на проверку при регистрации.

Кто-нибудь использует TFS 2012 в сценарии, описанном выше? Или вы просматриваете все проверки в отдельном запросе на просмотр?

Ответ 1

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

Если вы абсолютно должны придерживаться этой практики, вы можете обойти это, создав выделенную ветку для разработки функции до тех пор, пока она не будет готова для просмотра, затем выполните слияние (которое создает ожидающие изменения в родительской ветке) и запросит проверку этого слияния перед его проверкой.

Наиболее очевидными недостатками являются:

административные накладные расходы (создание ветвей, ведение определений построений, выполнение объединений, отображение и получение ветвей на машине разработчика)
изменения, еще не объединенные с родительским филиалом, недоступны другим разработчикам. Но поскольку эта функция даже не готова для просмотра, она, вероятно, не готова к использованию, и, следовательно, это не должно быть проблемой.
изменения в родительской ветке недоступны в ветке для подготовки к просмотру до тех пор, пока они не будут объединены, но те, которые были запущены, были тривиальными и могут быть выполнены в ночное время, даже автоматизированы с помощью script.

Ответ 2

Насколько я знаю, невозможно в TFS2012.

Грязный трюк, взятый из этого источника ссылка:

В чистой рабочей области со всеми файлами в их последней версии проверьте каждый отдельный файл, который вы хотите просмотреть отдельно (для этого требуется рабочее пространство сервера). Со всеми файлами, которые вы хотите включить в обзор проверить, запросить обзор. Запрос на отзыв будет создан со всеми извлеченные файлы (независимо от внесенных в них изменений)

Отменить все ожидающие изменения в локальной рабочей области.

Ответ 3

Использование "commit" здесь путается. "Commit" не применяется к управлению источником TFS. Вы имеете в виду, что разработчик несколько раз проверяет изменения в контролере источника, прежде чем запрашивать обзор?

Проверка изменений перед выполнением обзора поражает цель обзора. Идея состоит в том, чтобы сделать обзор, прежде чем плохой код застрял в источнике. Таким образом, запрос на проверку кода связывает ожидающие изменения с полками (которые НЕ находятся в контроле источника: считайте его временной ветвью). Если вы зарегистрируетесь до завершения проверки, что вы будете делать, если рецензент решит, что код необходимо отредактировать? Откат? Создать набор изменений, не связанных с рабочим элементом? Это боль.

Процесс должен быть:

1) Выберите рабочий элемент.

2) Работайте.

3) Выполните какую-либо сборку и выполните любые автоматические тесты. Это делается для локальной рабочей области.

4) Запросить проверку. Обратите внимание, что код еще не проверен на исходный контроль.

5) Рецензент выполняет проверку, отправляет комментарии назад.

6) Выполните любое действие, требуемое при просмотре.

7) Получите последние данные от источника управления.

8) Build/Test

9) Проверьте, успешно ли выполнены все вышеперечисленные шаги.

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

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

Изменить 2.0 Рабочий процесс для реализации:

1) Создайте запрос на проверку кода. Вам понадобится политика, чтобы все знали, что этот обзор еще не готов. Это создаст элемент проверки кода. Обратите внимание на его номер.

2) Когда вы проверяете код, который должен быть связан с ранее созданным обзором кода, свяжите его с рабочей частью проверки кода. Это можно сделать на странице ожидающих изменений, выберите параметр, чтобы связать рабочий элемент по идентификатору.

3) После того, как все необходимые изменения будут связаны с обзором, вам понадобится способ сообщить всем, что обзор будет готов.

В качестве альтернативы вы можете просто добавить номер набора изменений в качестве общего комментария к запросу проверки кода для "более свободной" связи.

Независимо от того, какой маршрут вы берете, похоже, вы пытаетесь использовать этот инструмент для чего-то, для которого он не предназначался. Я думаю, что это можно сделать, но для этого потребуется эксперимент. Удачи!