Я использую TFS с Jira для управления командными задачами. Я хочу интегрировать инструмент Code Review в процесс разработки.
Когда я пытаюсь использовать тигель, я обнаруживаю, что он не поддерживает TFS.
Я хочу знать, есть ли для этого хорошее и надежное решение, позволяющее мне использовать тигель с TFS.
дополнительно, если есть другие предложения для инструмента просмотра кода для VS и JIRA.
Благодарить!
Некоторое время назад мы решили запустить Crucible в нашем проекте. В нашем проекте используется TFS 2012. Мы используем одну ветку в TFS под названием «dev» в качестве ствола, то есть ветку, в которой разработчики совершают коммиты и где находится необработанный код. Вторая ветвь, в которой находится код выпуска, называется 'main'. Наш рабочий процесс для экспертной оценки был следующим:
Наша цель состояла в том, чтобы улучшить шаги 2 и 3. Crucible - отличный инструмент, но он не поддерживает TFS из коробки, поэтому мы решили использовать мост TFS. На самом деле, есть два основных варианта: использовать tfs-> svn или tfs-> git. Наконец, мы решили использовать tfs-> git bridge, потому что создание веток в git чрезвычайно дешево и, возможно, было полезно (да), потому что мы думали использовать ветки в git для выходных наборов полок в TFS. Наконец, мы решили использовать git. Пока я знаю только 2 варианта преобразования TFS в git:
Вот шаги, которые мы сделали для достижения цели: 1. Во-первых, мы клонировали нашу ветку TFS «dev» в репозиторий «dev». Нам нужна была только эта ветка, и у нас нет обратных слияний из «основной» ветки. Мы попытались сделать это с помощью clone, но безуспешно:
git tfs clone http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
Эта команда клонирует полную историю из TFS, но кажется, что наша ветка TFS довольно большая, и в какой-то момент git-tfs вылетал с System.OutOfMemoryException исключением. В другой раз мы потерпели неудачу за исключением того, что был превышен максимальный предел пути, мы нашли обходной путь, сопоставив каталог рабочей области с как можно более коротким путем, как показано ниже:
git config --global git-tfs.workspace-dir e:\ws
Когда мы потерпели неудачу с командой clone, мы использовали quick-clone. Это клонирование, начиная с любого момента истории, из любого набора изменений.
git tfs quick-clone -c545532 http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
Опция -c545532 - это номер набора изменений, с которого начинается копирование. Раз в год мы обновляем все исходные файлы с новым заголовком, поэтому мы просто копируем с начала текущего года. Таким образом, у нас должна быть вся необходимая история для создания веток из наборов полок. Если бы вы не использовали здесь аргумент -c, у вас вообще не было бы истории, потому что quick-clone копирует только историю, если вы ее попросите. После клонирования репозитория мы написали «скрипт» и поместили его в планировщик задач, чтобы он запускался каждые 5 минут. Сценарий просто проверяет наличие новых коммитов в TFS и создает новые ветки в нашем репозитории git. Опять же, здесь мы используем git-tfs. Чтобы получить все новые коммиты, мы вызываем pull команда:
git tfs pull
Чтобы убрать набор полок TFS на определенную ветку git, мы используем команда unshelve:
git tfs unshelve -user=TFSDOMAIN\Username "Shelveset Name Here" Branch_Shelveset_Name_Here
Эта последняя команда создает ветку 'Branch_Shelveset_Name_Here' в git из shelveset 'Shelveset Name Here' в TFS. Имя полочного набора может содержать пробелы и некоторые escape-символы, поэтому наш «скрипт» убирает такие случаи. Как я уже сказал, создание веток на git очень дешево, поэтому у нас нет с этим проблем. Если что-то было помещено в репозиторий git, мы вызываем API-интерфейс Crucible, чтобы обновить его. Кстати: чтобы сделать репозиторий git видимым в сети, я только что установил SCM-Server . Crucible был установлен и настроен для использования нашего имени пользователя и пароля домена, поэтому мы также получаем уведомление по электронной почте. В результате мы значительно улучшили этапы 2 и 3 нашего рабочего процесса, и он работает несколько месяцев, и мы довольны этим.
Наш рабочий процесс стал:
Работая с этим, я заметил несколько проблем:
Проблема 1: если вы добавили новый файл в проект и отложили его, вы не увидите его в репозитории git, потому что git-tfs не может найти для него родительский коммит. Я не уверен, что это ошибка этого инструмента или нет, но самый простой способ решения этой проблемы - наличие хотя бы одного файла в наборе полок с существующим родительским элементом. Например, вы добавили 2 новых файла и хотите отправить их на рассмотрение. Вместо того, чтобы создавать набор полок с этими файлами, просто коснитесь любого файла, который уже находится в репозитории git (сделайте его ожидающим в Visual Studio), и, наконец, вы сможете создать набор полок с тремя файлами (2 новых файла [добавить] и 1 для редактирования [изменить] ). В этом случае все работает, и git-tfs может убрать из полки набор полок TFS в ветку git., Т.е. мы можем увидеть это в тигле.
Проблема 2. Однажды наша HEAD в репозитории git отсоединилась от ветки master. Как только это произошло, в Crucible не было новых наборов изменений. Я исправил это командой:
git rebase HEAD master
Я нарисовал картину, как это все работает в нашем проекте, может быть, это будет полезно:
Вы можете интегрировать Mira и TFS с TaskTop, а затем использовать инструменты проверки кода, встроенные в Visual Studio.
Я думаю, это ваши лучшие варианты.
