Управление развитием команды с помощью SSAS, TFS и BIDS
В настоящее время я являюсь одним разработчиком BI для корпоративного хранилища данных и куба. Я использую SQL Server 2008, SSAS и SSIS в качестве основного набора инструментов. Я использую Visual Studio +BIDS и TFS для своей IDE и системы контроля версий. Я собираюсь взять на себя несколько проектов с офшорным поставщиком, и я беспокоюсь об управлении изменениями. Моя главная задача - управлять слияниями и изменениями между мной и оффшорной командой. Объединение и управление изменениями в SQL & XML только для одного человека - это плохо, но для многих разработчиков это кажется кошмаром. Есть мысли о том, как лучше структурировать разработку, зная, что иногда нет способа избежать внесения изменений в один файл несколькими пользователями?
4 ответа
Файлы SSIS, SSAS и SSRS не допускают слияния. Они хранятся в XML-файле, который радикально изменяется - даже с небольшими изменениями (такими как изменение свойства) - поэтому слияние становится действительно невозможным.
Так что перестаньте думать о параллельной разработке на одном файле. Вам нужно подумать, как можно добиться того, чтобы людям не нужно было заниматься параллельной разработкой одного файла. Так что начните с отключения многократной проверки файла. Возможно, вы даже захотите включить опцию, чтобы получить последнюю версию на кассе.
Тогда начните думать, как вы можете добиться того, чтобы люди могли работать независимо. Это больше в том, как вы структурируете работу и файлы:
- Дайте людям их собственную область, над которой они могут работать. Один пакет служб SSIS разрабатывается только лицом X в любой момент времени.
- Сделайте файлы меньшего размера, чтобы изменения, необходимые двум людям для работы в одном файле, были небольшими.
Я дал отзыв команде разработчиков о несовместимости BIDS для слияния. Это известная проблема, но ее будет трудно решить. Они не знают, когда можно будет по-настоящему заняться параллельной разработкой этих файлов. До этого держитесь подальше от параллельного развития.
Как отметил Эвальд Хофман, службы SSAS и SSIS не поддерживают слияние.
В одной среде я работал решил проблему следующим образом:
- используйте SSIS только тогда, когда это необходимо (алгоритм фазз или что-то подобное). Заменяйте пакеты служб SSIS так часто, как это возможно, кодом SQL (см., Например, Linked Server для datasync. И команду MEARGE для создания таблицы измерений / фактов).
- Создайте свою структуру хранилища данных следующим образом:
- построить 2 базы данных, одну для "необработанных исходных данных" из исходных систем и одну ("базовую" базу данных) для представлений и таблиц измерений и фактов
- использовать процедуры, которые могут развернуть всю базу данных "stage"
- поместите структуру базы данных "stage" в ваш репозиторий
создайте приложение на C#, которое строит ваши измерения и кубы с помощью AMO API (я знаю, это трудная работа с самого начала, но она того стоит - подумайте о том, что вы получите - посмотрите на плюсы ниже)
добавьте базу данных stage и приложение C# в свой репозиторий (TFS/Git и т. д.)
Плюсы этой структуры:
- у вас есть объединяемая структура, которую вы можете поместить в свой репозиторий
- вы используете AMO API ведьма
- Вы можете автоматизировать генерацию новых разделов
- Вы можете использовать процедуры для автоматизации и клонирования групп измерений в разные кубы (что, я думаю, иногда приносит большую пользу!)
- Вы можете перенести перевод на другой язык и легко импортировать его (дизайнер кубов, вероятно, не лучший переводчик)
Минусы:
- продавец, вероятно, не адаптирует эту структуру
- Вы должны платить больше (из-за более высоких требований к навыкам или из-за обучения его вашей индивидуальной структуре)
- вам, вероятно, нужны знания по новому языку C# - если у вас его еще нет
Заключение:
- есть возможность получить среду, удобную для слияния
- Вы потеряетесь в хороших инструментах "нажми и беги", например, BIDS, - но вы попадете в процесс высокой функциональности автоматизации
- аутсорсинг может быть убыточным из-за высокой индивидуализации
http://code.google.com/p/support/wiki/DVCSAnalysis
может быть, лучше тег DVCS? https://stackru.com/questions/tagged/dvcs
Пока обе команды используют ставки и TFS, это не должно быть проблемой.
Предполагая, что ваш tsql-код проверен на контроль исходного кода в одном файле на объект, объединение кода TSQL является простым, поскольку оно основано на тексте. Я нашел, что проекты базы данных VSTS помогают с этим.
Объединение исходных файлов служб SSIS и MSAS на основе XML может быть затруднительным, как указано ниже. Чтобы облегчить некоторые проблемы, я обнаружил, что ограничение каждого пакета одним потоком данных или логической единицей работы помогает снизить конкуренцию разработчиков в пакетах. Затем я вызываю эти пакеты из одного или нескольких мастер-пакетов. Я также пытаюсь вывести все мои исходные запросы tsql с помощью sprocs, view или udfs, чтобы уменьшить необходимость редактирования пакета. Использование файлов конфигурации и переменных также помогает в меньшей степени.
Кубы MSSAS немного сложнее. Мое лучшее предложение - поискать сторонний xml-инструмент для различий. Мне удалось успешно объединить небольшие изменения, используя стандартные текстовые инструменты, но это может быть сложной задачей.