#tfsbuild #database-deployment
#tfsbuild #база данных-развертывание
Вопрос:
У меня следующая проблема.
Я пытаюсь настроить процесс сборки TFS по умолчанию, добавив шаг, на котором база данных развертывается с использованием проекта базы данных. Я строго следовал этим шагам, единственное отличие в том, что я сделал это в другой части рабочего процесса. Однако развертывание базы данных всегда завершается неудачей со следующей ошибкой: *** The deployment manifest file Database.Project.Name.deploymanifest does not exist .
Вот командная строка, которая выполняется:
C:Program Files (x86)Microsoft Visual Studio 10.0VSTSDBDeployVSDBCMD.EXE /a:Deploy /dd /dsp:Sql /cs:"Data Source=DB-Server;Initial Catalog=DB.Name;User Id=username;Password=password;" /manifest:Database.Project.Name.deploymanifest
Я дважды проверил несколько вещей — VSDBCMD.EXE утилита действительно существует по указанному пути на сервере сборки, в базе данных.Файл Project.Name.deploymanifest действительно существует в каталоге удаления сборки, и BuildDetail.DropLocation (который задан в качестве рабочего каталога в рабочем процессе) поле действительно указывает на этот каталог. Похоже, что все должно работать, но это не так. Каковы могут быть другие возможные причины этой проблемы? Заранее спасибо.
Комментарии:
1. Просто предположение: вы пробовали использовать полный путь к файлу deploymanifest в /manifest 😕
2. К сожалению, невозможно задать полный путь декларативно. Это связано с тем, что каждая удаленная папка (где находится deploymanifest) имеет другое имя, что-то вроде BuildName_Date.BuildNumber.
3. Вы можете использовать vbscript в рабочем процессе, чтобы установить эти параметры программно. Например, в параметре действия аргументов команды вы можете создать эту строку программно, используя значение hte BuildDetail.DropLocation.
4. Да, то, что предложил Дилан, должно помочь.
5. @Дилан Смит: Спасибо за ответ. Попробовал это — та же ошибка.
Ответ №1:
Наконец-то я нашел обходной путь. Вместо BuildDetail.DropLocation я использую рабочий каталог агента сборки. Пожалуйста, обратите внимание, что это всего лишь обходной путь, а не полное решение проблемы, и я все еще понятия не имею о том, почему файл deploymanifest не был доступен. Однако этот подход, по крайней мере, работает…
Комментарии:
1. @Alfred, к сожалению, потерял этот проект, но, насколько я помню, я только что выяснил абсолютный путь к рабочему каталогу агента сборки и указал его в свойстве Workspace рабочего процесса. Конечно, не лучший подход (жесткое кодирование всегда плохо), но, по крайней мере, это сработало.