1

Недавно у меня был неудачный опыт изменения размера поля в таблице, которая использовалась в пакетах SSIS. Разработчик, который написал пакеты, с тех пор вышел на пенсию и сгруппировал их в одном проекте VS BI. Она разработала их исключительно на своем локальном ПК и перевела их на общий диск, когда она ушла.Лучший способ добавления проектов SSIS (Business Intelligence) в SourceSafe?

Любой, кто знает уровень защиты в SSIS, знает, что произошло дальше. Она сохранила их с параметром EncryptSensitiveWithUserKey по умолчанию, поэтому я не смог изменить пакет из-за того, что я не был ею, и я не был на ее машине. Ее учетная запись AD уже давно отключена, и ее машина может проверять людей в продуктовом магазине сейчас, насколько я знаю.

Мне пришлось воссоздать пакеты с нуля. К счастью, уровень защиты не позволяет вам экономить или строить, а не смотреть на вещи в дизайне, поэтому я смог воспроизвести то, что она сделала, но это был долгий, утомительный процесс, который занял большую часть полного дня.

Мой вопрос:: Мы используем SourceSafe для поддержки наших проектов, поэтому здесь будет запущен новый проект SSIS. Учитывая следующее:

  • У каждого из нас есть наши собственные компьютеры с рабочими папками, которые синхронизируются с SourceSafe
  • Мы не имеем возможность сохранить проект на самом сервере базы данных; мы можем использовать только pacakges.
  • Детали программного обеспечения: MS Visual Studio 2008, VSS 8.0, MS SQL Server 2008 R2

Что бы быть лучшим вариантом безопасности для настройки нашего проекта с? Я сразу вижу, что DontSaveSensitive будет логичным подходом, но я не знаю, откуда будут передаваться пароли. Я думаю, что файл конфигурации, но я не знаю, как настроить это для развертывания SSIS.

Спасибо!

+0

Вы развертываете пакеты в самой базе данных SQL Server, а не в «хранилище пакетов», правильно? У вас есть возможность создать таблицу на сервере для обработки конфигурации (паролей) или вам нужно сосредоточиться на использовании конфигурации на основе файлов? Для полноты других параметров конфигурации используются параметры реестра, переменные среды, родительский пакет и ручное назначение времени выполнения. – billinkc

+0

В стороне: если это вообще возможно, избегайте VSS и начинайте использовать Team Foundation в качестве системы управления исходным кодом. (VSS ** намного ** менее надежный, чем TFS, который использует SQL Server как хранилище, а не файловую систему.) См. [Миграция из Visual SourceSafe] (http://msdn.microsoft.com/en-us/library /ms253060(v=vs.90).aspx/html?ppud=4) в MSDN для получения дополнительной информации. –

+0

Поверь мне, если бы я мог. Я ненавижу VSS. Если я буду выступать за другой маршрут, я посмотрю, будет ли босс слушать. – Ryan

ответ

1

Используйте VSS в качестве источника для поставщика Visual Studio и добавьте проект SSIS так же, как и любой другой исходный проект. После установки VSS перейдите в раздел «Инструменты \ Параметры \ Управление источником» и установите VSS в качестве поставщика.

Я использую эту установку в течение нескольких месяцев. Насколько я могу судить, нет никакой разницы между любыми моими проектами C# и моими проектами SSIS в отношении VSS.

+0

Я предполагаю, что другие могут открыть проект и работать тоже? Я осторожно b/c вариантов безопасности. – Ryan

+0

Вы можете управлять разрешениями пользователей через VSS Administrator. Если вы не дадите пользователю разрешение на проверку/проверку, он не может редактировать проект. http://msdn.microsoft.com/en-us/library/t5w38ke8(v=vs.80).aspx – Rachel

+0

Я пока этого не делал, но, когда позволяет время, я вернусь к нему и расскажу, что произойдет. – Ryan

Смежные вопросы