SSIS, dtsx и пакеты развертывания

Поправьте меня, я ошибаюсь, но для любого развертывания я считаю, что должно быть как минимум два файла: .SSISDeploymentManifest и .dtsx. .SSISDeploymentManifest действует как эквивалентный пакет установщика Windows, который указывает на .dtsx. Dtsx - это фактический пакет «вещей», который каким-то образом упоминается как внешний файл, когда вы запускаете установщик. Когда вы его устанавливаете, пакет добавляется в список пакетов ssis для этого экземпляра.

Ваши предположения в основном верны. Вам не нужен манифест развертывания, но он может быть удобен. Кроме того, вам не нужно выполнять развертывание на экземпляре SQL Server. У вас также есть возможность выполнить развертывание в файловой системе. Я объясню оба ниже.

Относительно вашего 1-го вопроса:

Управление версиями:

Убедитесь, что вы разрабатываете и проверяете свои пакеты dtsx через Visual Studio. Пометьте свои выпуски в sourceafe или любом другом элементе управления версиями, который вы используете. Если вы проверяете и маркируете, вы сможете легко вернуться к предыдущей версии. Как вы упомянули, вы также можете просто сохранить копию своего старого каталога bin, но, естественно, поместить их в устаревшие подпапки или что-то в этом роде. Однако это не заменяет надлежащий контроль версий.

По поводу вашего 2-го вопроса:

Развертывание:

Как говорится на другом плакате, сначала вам нужно принять решение:

а) Развертывать пакеты в файловой системе б) Развертывать пакеты в MSDB

У каждого есть свои преимущества, и у каждого свои предпочтения. Я использовал оба, но предпочитаю файловую систему, потому что она более прозрачна, но есть еще кое-что, что нужно поддерживать.

Подробнее об этом см. В этом сообщении: http://blogs.conchango.com/jamiethomson/archive/2006/01/05/SSIS_3A00_-Common-folder-structure.aspx

Код находится в пакете dtsx. Как правило, чтобы сделать ваши пакеты переносимыми, вы также абстрагируете свои строки подключения и другую настраиваемую информацию в файл конфигурации (.dtsconfig) или переменную среды (файл не требуется). См. BOL, чтобы узнать больше о конфигурации.

Файл манифеста содержит метаданные о том, какие файлы dtsx и config нужно установить. Если вы откроете его, вы увидите, что это простой читаемый файл xml.

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

Для меня файл манифеста более полезен для развертывания на SQL Server, чем в файловой системе. На самом деле, все, что он делает, - это копирует файлы dtsx и config и помещает их туда, куда вы указываете. Вы также можете легко проинструктировать администратора базы данных скопировать ваши файлы dtsx в общую папку на сервере, а файлы конфигурации - в другую папку на том же сервере.

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

Так много нужно знать о настройке / развертывании / управлении версиями пакетов SSIS. Но, надеюсь, это поможет вам встать на правильный путь.

Когда вы экспортируете свои пакеты DTS с помощью мастера импорта / экспорта в SQL Server, у вас есть возможность сохранить их на SQL Server или локально в файловой системе.

Что касается версий ваших пакетов SSIS, вам необходимо запросить SSISDB для извлечения номеров версий. Раздражает, что такая информация не отображается непосредственно в Management Studio, но до тех пор, пока она не появится, кому-то это может пригодиться:

SELECT prj.[name] as Project
      ,pkg.[name] as Package
      ,pkg.[version_major]
      ,pkg.[version_minor]
      ,pkg.[version_build]
FROM [SSISDB].[internal].[packages] as pkg
JOIN [SSISDB].[internal].[projects] as prj
ON pkg.[project_id] = prj.[project_id]
ORDER BY prj.[name]