Сколько пакетов вы говорите? Если это сотни пакетов, то какой конкретной проблемы вы пытаетесь избежать? Вот несколько вещей, которые вы можете пытаться избежать, основываясь на своем посте:
Медленное решение и время загрузки проекта при запуске в BIDS. Я полагаю, это может быть раздражающим время от времени. Но если вы держите BIDS открытым весь день, это будет стоить один раз в день.
Медленное решение и время загрузки проекта, когда вы получаете последнее определение решения из вашей системы контроля версий. Опять же, я полагаю, это может время от времени раздражать, но как часто вам нужно обновлять весь раствор? Если вы разбиваете решение на отдельные проекты, вам нужно только обновить проект. Вам нужно будет только обновить все решение, если вы хотите получить доступ к новому проекту в рамках решения.
Что вы подразумеваете под "одним огромным XML-файлом"? Файл решения представляет собой XML-файл, который отслеживает проекты. Каждый файл проекта представляет собой XML-файл, который отслеживает его пакеты служб SSIS. Таким образом, если у вас есть 1000 пакетов служб SSIS, равномерно распределенных по 10 проектам в одном решении, то в каждом файле будет отслеживаться не более 100 объектов. По опыту могу вам сказать, что у меня были проекты служб Reporting Services с большим количеством RDL-файлов, чем это, и потребовалось всего несколько секунд, чтобы правильно загрузить решение в BIDS. И, как указал @revelator, настоящие пакеты служб SSIS представляют собой собственные отдельные файлы XML. Любая система контроля версий должна отслеживать каждый из них как отдельные файлы и не объединять их в «один огромный XML-файл». Если вы уточните, что вы подразумеваете под этим пунктом, то, я думаю, вы получите лучшую помощь по этому вопросу.
Независимо от того, используете ли вы один пакет или 1000 пакетов, вы не будете делать это в интерактивном режиме из BIDS. Возможно, вы сначала развернете пакеты на сервере, а затем запустите пакеты на сервере. Если это так, то вам нужно будет вызвать пакеты, вероятно, с заданием агента SQL Server. Независимо от того, объединяете ли вы пакеты, заставляя каждый пакет вызывать другой пакет, или если вы связываете пакеты, когда задание вызывает каждый пакет как отдельный шаг задания, вы все равно можете отслеживать, где вы находитесь в цепочке, с помощью регистрации. Если вы вызываете пакеты с заданиями, вы также можете отслеживать их по шагам заданий. Я управляю хранилищем данных с множеством пакетов и в первую очередь полагаюсь на разделение процессов на задания, каждое из которых содержит один или несколько пакетов. Я также связываю задания с помощью команд запуска задания, чтобы упростить мониторинг производительности логических групп нагрузок. Кроме того, каждый пакет показывает время выполнения в истории заданий на уровне шага. Кроме того, в каждой хранимой процедуре и пакете есть настраиваемое ведение журнала, показывающее, сколько секунд и строк потребовалась отдельная загрузка данных или хранимая процедура, чтобы я мог устранить узкие места производительности.
Что бы вы ни делали, не полагайтесь на интерактивный запуск пакетов для отслеживания производительности! Вы не получите оптимальной производительности при использовании ETL на своей машине, не говоря уже о запуске с графическим интерфейсом. Запускайте пакеты в заданиях на серверах, а не на рабочих столах. Интерактивно работающие пакеты предназначены только для создания и устранения неполадок отдельных пакетов, а не для ежедневного администрирования ETL.
Если вы создаете универсальные пакеты, которые изменяют свои цели и источники на основе параметров, то вам, вероятно, необходимо построить контрольную таблицу в базе данных, которая отслеживает прогресс. Если вы просто перемещаете данные из одной большой системы в другую как одноразовое событие, то вы, вероятно, собираетесь разделить нагрузку на небольшие наборы пакетов и иметь отдельные задания для каждого из них, чтобы вам было легче управлять восстановлением после сбоев. Если вы намереваетесь создать что-то, что регулярно выполняется для перемещения данных, то как может иметь смысл 2 дня непрерывной работы для одного процесса? Похоже, основные данные изменятся на вас в течение 2 дней ...
Если вы беспокоитесь о том, какую систему контроля версий использовать для управления пакетными проектами служб SSIS, тогда я могу сказать, что подойдет практически любой. Я использовал Visual SourceSafe и Perforce в разных компаниях, и обе они имеют одинаковые базовые функции регистрации и проверки отдельных пакетов. Я уверен, что любая система контроля версий, которая интегрируется с Visual Studios, сделает это за вас.
Надеюсь, вы найдете что-то полезное в вышеприведенном и удачи в вашем проекте.