Управление развитием команды с SSAS, TFS и BIDS - PullRequest
Новая
       37

Управление развитием команды с SSAS, TFS и BIDS

5 голосов
/ 16 апреля 2010

Я в настоящее время являюсь одним разработчиком BI для корпоративного хранилища данных и куба. Я использую SQL Server 2008, SSAS и SSIS в качестве основного набора инструментов. Я использую Visual Studio + BIDS и TFS для своей IDE и системы контроля версий. Я собираюсь взять на себя несколько проектов с офшорным поставщиком, и я беспокоюсь об управлении изменениями. Моя главная задача - управлять слияниями и изменениями между мной и оффшорной командой. Объединение и управление изменениями в SQL & XML только для одного человека - это плохо, но для многих разработчиков это кажется кошмаром. Любые мысли о том, как лучше структурировать разработку, зная, что иногда нет способа избежать внесения изменений в один файл несколькими людьми?

Ответы [ 4 ]

3 голосов
/ 08 ноября 2010

Файлы SSIS, SSAS и SSRS не допускают слияния. Они хранятся в XML-файле, который радикально изменяется - даже с небольшими изменениями (такими как изменение свойства) - поэтому объединение становится действительно невозможным.

Так что перестаньте думать о параллельной разработке одного файла. Вам нужно подумать, как можно добиться того, чтобы людям не нужно было заниматься параллельной разработкой одного файла. Так что начните с отключения многократной проверки файла. Возможно, вы даже захотите включить опцию, чтобы получить последнюю версию на кассе.

Тогда начните думать, как вы можете добиться того, чтобы люди могли работать независимо. Это больше в том, как вы структурируете работу и файлы:

  • Дайте людям их собственную область, над которой они могут работать. Один пакет служб SSIS разрабатывается только лицом X в любой момент времени.
  • Создайте файлы меньшего размера, чтобы изменения, необходимые двум людям для работы в одном файле, были небольшими.

Я дал отзыв команде разработчиков о несовместимости BIDS для слияния. Это известная проблема, но ее будет трудно решить. Они не знают, когда можно будет по-настоящему заняться параллельной разработкой этих файлов. А пока держитесь подальше от параллельной разработки.

0 голосов
/ 21 сентября 2015

Как отметил Эвальд Хофман, SSAS и SSIS не допускают слияния.

В одной среде я работал решил проблему следующим образом:

  • используйте SSIS, только когда это необходимо (алгоритм фазз или что-то подобное). Заменяйте пакеты служб SSIS как можно чаще с помощью кода SQL (см., Например, Связанный сервер для синхронизации данных. И команду MEARGE для создания таблицы измерений / фактов).
  • построить структуру хранилища данных следующим образом:
  • построить 2 базы данных, одну для «необработанных исходных данных» из исходных систем и одну («промежуточную» базу данных) для представлений измерений и фактов и таблиц
  • использовать процедуры, которые могут развернуть всю базу данных "stage"
  • поместите структуру базы данных "stage" в ваш репозиторий

  • создание приложения на C #, которое строит ваши измерения и кубы с помощью AMO API (я знаю, это трудная работа с самого начала, но она того стоит - подумайте, что вы получите - посмотрите в плюсах ниже)

  • добавить базу данных stage и приложение C # в свой репозиторий (TFS / Git и т. Д.)

Плюсы этой структуры:

  • у вас есть объединяемая структура, которую вы можете поместить в свой репозиторий
  • вы используете AMO API, у которого
  • вы можете автоматизировать генерацию новых разделов
  • Вы можете использовать процедуры для автоматизации и клонирования групп измерений в разные кубы (что я иногда считаю большим преимуществом!)
  • Вы можете перенести перевод на другой язык и легко импортировать его (дизайнер кубов, вероятно, не лучший переводчик)

Минусы:

  • продавец, вероятно, не адаптирует эту структуру
  • вы должны платить больше (либо из-за более высоких требований к навыкам, либо из-за обучения его вашей индивидуальной структуре)
  • вам, вероятно, нужны знания по новому языку C # - если у вас еще нет

Вывод:

  • есть возможность получить среду, удобную для слияния
  • Вы потеряетесь в хороших инструментах «нажми и беги», например. BIDS - но войдет в процесс высокой функциональности автоматизации
  • Аутсорсинг может быть убыточным из-за высокой индивидуализации
0 голосов
/ 26 июня 2010

Пока обе команды используют ставки и TFS, это не должно быть проблемой.

при условии, что ваш tsql-код зарегистрирован для управления исходным кодом в одном файле на объект, объединение кода TSQL является простым, поскольку оно основано на тексте. Я нашел, что проекты базы данных VSTS помогают с этим.

Объединение исходных файлов SSIS и MSAS на основе XML может быть затруднительным, как указано ниже. Чтобы облегчить некоторые проблемы, я обнаружил, что ограничение каждого пакета одним потоком данных или логической единицей работы помогает снизить конкуренцию разработчиков в пакетах. Затем я вызываю эти пакеты из одного или нескольких мастер-пакетов. Я также пытаюсь вывести все мои исходные запросы tsql с помощью sprocs, view или udfs, чтобы уменьшить необходимость редактирования пакета. Использование файлов конфигурации и переменных также помогает в меньшей степени.

Кубики MSSAS немного сложнее. Мое лучшее предложение - поискать сторонний xml-инструмент для различий. Мне удалось успешно объединить небольшие изменения, используя стандартные текстовые инструменты, но это может быть сложной задачей.

0 голосов
/ 05 мая 2010
...