Что может привести к сбою развертывания dacpa c на одном сервере, а не на другом? - PullRequest
Новая
       47

Что может привести к сбою развертывания dacpa c на одном сервере, а не на другом?

0 голосов
/ 03 марта 2020

Есть много вопросов по этому вопросу. Вот один - SSDT не удалось опубликовать sh: «Невозможно подключиться к главному или целевому серверу» . Я получаю ту же ошибку: 

2020-03-03T13:51:28.5079081Z *** Could not deploy package.
2020-03-03T13:51:28.5080013Z Unable to connect to master or target server 'databasename'. You must have a user with the same password in master or target server 'databasename'.
2020-03-03T13:51:28.6466638Z ##[error]Publishing to database 'databasename' on server 'server'. 
Initializing deployment (Start) 
Initializing deployment (Failed)

Я развертываю через Azure DevOps. Он отлично работает, когда я развертываюсь в двух наших нижних средах (которые работают на одном сервере разработки), но сегодня утром это было наше первое производственное развертывание. SQL Сервер 2016 работает на обоих серверах. Есть разница в версиях, хотя. Сервер разработки работает Microsoft SQL Server 2016 (RTM) - 13.0.1601.5 (X64), а производство работает Microsoft SQL Server 2016 (RTM-CU5) (KB4013105) - 13.0.2197.0 (X64). Для обоих уровней совместимости установлено значение 130.

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

steps:
- task: SqlDacpacDeploymentOnMachineGroup@0
  displayName: 'Deploy using : dacpac'
  inputs:
    DacpacFile: '$(System.DefaultWorkingDirectory)/database/Database.dacpac'
    TargetMethod: publishProfile
    PublishProfile: '$(System.DefaultWorkingDirectory)/Database/develop.publish.xml'

Единственное различие между этапом разработки и этапом производства заключается в том, что публикация sh профиль отличается. И единственные различия между этими двумя файлами * publi sh profile XML - это имя сервера и имя базы данных.

Вот профиль разработки: 

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <IncludeCompositeObjects>True</IncludeCompositeObjects>
    <TargetDatabaseName>develop</TargetDatabaseName>
    <DeployScriptFileName>develop.sql</DeployScriptFileName>
    <ProfileVersionNumber>1</ProfileVersionNumber>
    <TargetConnectionString>validconnectionstring</TargetConnectionString>
    <BlockOnPossibleDataLoss>False</BlockOnPossibleDataLoss>
    <GenerateSmartDefaults>True</GenerateSmartDefaults>
  </PropertyGroup>
  <ItemGroup>
    <SqlCmdVariable Include="dbEnvironment">
      <Value>develop</Value>
    </SqlCmdVariable>
    <SqlCmdVariable Include="migratedLegacyDatabase">
      <Value>Migration-Develop</Value>
    </SqlCmdVariable>
    <SqlCmdVariable Include="migrationSource">
      <Value>false</Value>
    </SqlCmdVariable>
  </ItemGroup>
</Project>

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

Чувствую, что я упускаю что-то очевидное, но я не уверен, что это такое. Я знаю, что это не легко воспроизводимая проблема, но если у кого-то есть какие-то идеи, я весь слух.

1 Ответ

1 голос
/ 04 марта 2020

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

1) Для сервера установлены правила firewall , поэтому что агент не может пройти.

2) Не уверен здесь, какой агент вы используете, но попробуйте с self-agent или запустите с группой развертывания работа в конвейере.

3) (это было бы наиболее легко пропустить, и я когда-либо встречал)

Проверьте SQL имя пользователя / пароль, и убедитесь, что это правильно.

4) Неправильная роль сервера.

У учетной записи пользователя, используемой в publish profile, могут быть права sysadmin. Кроме того, поскольку пользователи sysadmin на сервере сопоставляются с пользователем "dbo" в базе данных, что приводит к возникновению этой ошибки.

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

5) Включить Аутентификация в смешанном режиме .

Надеюсь, это поможет.

...