Управление версиями в SSIS и параллельная работа с файлом dtsx
Я работаю над созданием нового проекта SSIS с нуля. Я хочу работать с парой моих товарищей по команде. Я надеялся получить предложение о том, как у некоторых из нас может быть некоторый контроль исходного кода, чтобы немногие из нас могли одновременно работать над одним и тем же проектом SSIS (тот же файл dtsx, создание новых пакетов.) Версия: Служба интеграции SQL Server v11 Microsoft Visual Studio 2010
2 ответа:
По моему опыту, у любой системы управления версиями и проектов SSIS есть две возможности выйти из строя: добавление новых элементов в проект и одновременное внесение изменений в существующий пакет.
Добавление новых элементов
Проект SSIS имеет .расширение dtproj. Там, внутри, это" просто " XML, определяющий, что все принадлежит проекту. По крайней мере, для 2005/2008 и 2012+ на модели развертывания пакета. Модель развертывания проекта 2012+ несет в себе гораздо больше информация о состоянии пакетов в проекте.
При добавлении новых пакетов (или менеджеров соединений на уровне проекта или .файлы biml) внутренняя структура .файл dtproj будет изменен. Инструменты Diff обычно плохо справляются со слиянием XML. Или вообще по-настоящему. Таким образом, чтобы предотвратить необходимость объединения определения проекта, вам нужно найти стратегию, которая работает для вашей команды.
Я видел, что два подхода работают хорошо. Первый-это заранее определить все пакеты, которые вы думаю, тебе это понадобится. DimFoo, Таблицы Dimdate, DimFoo, DimBar, FactBlee. Проверьте этот проект и связанные с ним пустые пакеты, и все работают над тем, что есть. Когда начальный разрез пакетов будет завершен, вы убедитесь, что все синхронизированы, а затем добавите в проект еще несколько пустых пакетов. Идея здесь заключается в том, что есть один человек, обычно ведущий, который отвечает за изменение определения "главного" проекта, и каждый потребляет от их изменения.
Другой подход требует общения между членами команды. Если вы обнаружите, что пакет необходимо добавить, свяжитесь со своими товарищами: "мне нужно добавить новый пакет - кто-нибудь изменил проект?- Ответ должен быть отрицательным. Как только вы уведомили, что в определение проекта вносится изменение, сделайте это и немедленно зафиксируйте его. Идея здесь заключается в том, что люди фиксируют и синхронизируют/проверяют любую терминологию с большой частотой. Если вы, как разработчик, не поддерживаете свой локальный репозиторий в актуальном состоянии, вы будете в самое неподходящее время.
Параллельные правки
Не надо, правда, вот и все. Общая проблема, связанная с одновременных изменений в SSIS пакета заключается в том, что в дополнение к XML дифф вопроса выше, служб SSIS и включает верстку информации, а также задачи, так что я могу поменять планировку и сделать вещи потока снизу вверх или справа налево, и нет никаких существенных изменений в SSIS пакета, но как Siyual отмечает "слияние изменений в SSIS это кошмар топлива"
Если вы обнаружите, что ваши пакеты таковы большой и что разработчики должны делать параллельные правки, я бы предположил, что вы делаете слишком много там. Разложите ваши пакеты на более мелкие, более четко сфокусированные единицы работы, а затем контролируйте их выполнение через родительский пакет. Это позволит повысить степень детализации процесса разработки и отладки, а также избежать параллельного редактирования.
Файл dtsx-это в основном просто xml-файл. Сравните это с группой людей, пытающихся написать одну и ту же книгу. Я предлагаю использовать Team Foundation Server в качестве системы управления версиями. Таким образом, каждый может регистрироваться и сливать пакеты. Если у вас действительно нет такой возможности, попробуйте разбить процесс ETL на логические части и в конце создать главный пакет, который вызывает каждый дополнительный пакет в правильном порядке.
Пример: Предположим, вам нужно импортировать данные о запасах из одного источник, филиалы и другая информация о компании с внутреннего сервера и суммы продаж из различных внешних источников. После того, как вы собрали всю информацию, вы хотите соединить их и выполнить некоторые анализы.
Сначала вы проектируете целевые объекты базы данных, которые вам нужны, и отношения. Один из ваших членов создает пакет, который выполняет весь импорт в промежуточные таблицы. Другой парень, возможно, обрабатывает внешние источники и распараллеливает / оптимизирует загрузку. Вы бы построили пакет, который в объединяет ваши постановочные и производственные таблицы, возможно, историзирует и так далее. В конце у вас есть мастер-пакет, который вызывает каждый из упомянутых пакетов и, возможно, некоторые дополнительные журналы или что-то в этом роде.