Статьи

Развертывание: Git vs. TFS Showdown

Ноябрь 14, 2018

Я думаю, что все согласны с тем, что развертывание должно быть максимально простым. Похоже, все говорят о непрерывной интеграции / развертывании / доставке. Все больше и больше людей (и облачных провайдеров) начинают использовать систему управления исходным кодом mgmt в качестве решения для развертывания. В особенности Git кажется вполне подходящим для этого, то есть вы нажимаете на специальную ветку «deploy», которая автоматически выбирается, собирается и разворачивается каким-то роботом. Распределенный подход Git делает это простым, но возможно ли это и с TFS?

Недавно я запустил небольшой служебный проект для небольшой компании вместе с помощником. В качестве решения для развертывания мой друг предложил использовать задание cron на сервере, которое выполняет проверку TFS из некоторого места на нашем сервере VCS. Звучит круто, поэтому мы выбрали такой подход. Но оказалось, что не сразу все прошло так гладко, как ожидалось.

Структура проекта

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

  • Главный

    • ЦСИ

      • внешний интерфейс
      • библиотека
    • выпуск
    • release.bat

release.batФайл в основном выполняет следующие действия :

  1. rm -rf содержимого папки релиза
  2. сжатие файлов JavaScript из папки веб-интерфейса
  3. сжатие файлов JavaScript из папки библиотеки
  4. скопируйте результаты в папку релиза

Следующим шагом будет выполнение проверки изменений. Давайте посмотрим, как это ведет себя, когда я

  • добавить новый файл
  • удалить существующий
  • редактировать существующий

при использовании клиентов Git vs. TFS.

Использование Git

Предположим, я уже настроил git-репо в папке релизов. Я выполняю вышеупомянутые изменения, то есть добавляю новый файл, изменяю его и, наконец, удаляю существующий. Если я затем открою Windows GitHub Client , он сразу распознает изменения

Таким образом, завершить цикл развертывания так же просто, как ввести сообщение коммита и затем отправить изменения в удаленный репозиторий Git.

Использование TFS

Как насчет использования TFS? Снова предположим, что у меня уже есть рабочее пространство TFS в этой папке. Обратите внимание, что все операции выполняются вне контроля клиента TFS, так как они выполняются с помощью автоматического пакетного сценария. Таким образом, выполняя вышеописанный рабочий процесс (добавление / изменение / удаление некоторых файлов), наиболее естественным было бы выполнение проверки папки релизов. Обратите внимание, что для использования TFS вне Visual Studio я использую TFS Power Tools (2010), которые позволяют напрямую выполнять проверки из проводника Windows.

А?!? Проблема в том, что, как уже упоминалось, все изменения происходят вне контроля клиента TFS, потому что мы непосредственно выполняем удаление и модификации без явного выполнения проверки TFS или удаления TFS, как и ожидал бы клиент TFS. Это создает некоторые проблемы, потому что мы не можем выполнять эти операции TFS для каждого файла в сценарии автоматического развертывания (или, по крайней мере, легко).

К счастью , есть команда для решения этой проблемы: tfpt online. Он в основном сравнивает локальные модификации с изменениями на сервере и предлагает выполнить выполняемые операции (т. Е. Добавить / удалить / изменить), чтобы вернуться в синхронизированное состояние, которое затем может быть зафиксировано в хранилище. Команда для выполнения будет выглядеть следующим образом:

tfpt online .\release /recursive /adds /deletes /noprompt

Это приводит к следующему выводу

Getting your pending changes from the server...
Checking the status of C:\projects\applications\logging\Main\release... Done
Walking C:\projects\applications\logging\Main\release... Found 4

Edits:

release\admin:
config.js

Adds:

release:
aNewFile.txt

Deletes:
New Microsoft Office Word Document.docx

К тому времени — снова — выполняя проверку TFS, мы получаем то, что ожидали

Вывод

I guess the winner here in terms of simplicity is quite clear. Using Git just feels natural in that we do our modifications and then simply commit the changes to the server. It should be up to the tool to detect the differences. TFS on the other side delegates this task to the IDEs, wherefore when being used outside of their control, it performs poorly and feels very clumsy. To its defense however it is to say that my tests were against TFS 2010 and not the newest 2012 version which apparently is assumed to solve some of the issues like readonly flags on the filesystem etc.

29
Share: