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