Управление проектом Visual Studio, изменения активов через BimlStudio, контроль версий

Для тех, кто перешел от парадигмы ручного создания и модификации пакетов SSIS с использованием Visual Studio и TFVC, я изо всех сил пытаюсь «вникнуть» в BimlStudio и рабочий процесс системы управления версиями.

У меня есть проект BimlStudio, который создает проекты SSIS (файлы dtproj) и связанные пакеты, соединения и т. д. Я хочу поместить его все в систему управления версиями (.biml и .dtsx) с помощью BimlStudio и TFVC.

Как я могу более точно управлять изменениями исходного кода, чем то, что я, кажется, могу сделать в настоящее время.

Допустим, у меня есть один пакет, который мне нужно изменить. Пакет (как и все мои пакеты) определяется через внешние метаданные (метаданные, которые не являются частью моего проекта BIML). Единственное место, где я вношу изменения, это метаданные.

После изменения внешних метаданных я создаю свой проект BIML.

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

Я открываю свой обновленный проект в Visual Studio.

Используя файловый инструмент «diff», я сравниваю любой из пакетов с их предыдущей версией сборки. Каждый «diff» показывает, что каждый пакет имеет все новые идентификаторы GUID для всех его различных компонентов.

Разница с образцом пакета SSIS

Поскольку внутренние идентификаторы GUID всех пакетов меняются при каждой сборке BIML, я получаю безумное количество «шума» вокруг моего единственного изменения. Да, я мог бы назначить статические идентификаторы GUID пакета через метаданные пакета, но я не буду делать это для каждого подкомпонента в моем пакете. Или я? (Пожалуйста, скажите нет)

Можно возразить, что, поскольку я знаю, что изменилось, я регистрирую только один пакет. Но жизнь случается. Я ухожу с работы в пятницу, возвращаюсь в понедельник и думаю: «Что я изменил?» Или я передаю свою работу другому разработчику, и им нужно знать, что изменилось и т. д.

Как мне лучше всего справиться с этим?

Кроме того, включены ли артефакты SSIS (и все другие файлы в выходной папке моего проекта BimlStudio) в систему управления версиями BimlStudio или только файлы .biml, .bimlproj, .bspcap и .mst?

Если артефакты SSIS не включены в контроль версий BimlStudio, то их можно будет бесплатно добавить в TFVC через Visual Studio, верно?


person klzbrt    schedule 10.02.2020    source источник


Ответы (1)


Это подход, который мы использовали:

  • Не проверяйте пакеты SSIS. В решении BIML пакеты SSIS можно рассматривать как файлы сборки. Используйте файл игнорирования, чтобы исключить их. Поскольку они создаются динамически, они всегда будут меняться при повторном создании, как вы говорите.
  • (Назначение статических идентификаторов GUID подключениям)
person Magnus Lander    schedule 11.02.2020
comment
dtsx и .proj в качестве файлов сборки. Да. Хорошая точка зрения. Спасибо, Магнус! Я все еще придерживаюсь этого как принятого ответа (пока), но я ценю то, как другие справляются с этим сдвигом в работе. - person klzbrt; 11.02.2020