Получить изменения, связанные со сборкой

В TFS (обновление к 2013 году 4) Я пытаюсь написать сценарий PowerShell для копирования измененных файлов SQL, привязанных к сборке. Я могу получить и скопировать соответствующие файлы, если я знаю номер набора изменений, которого часто бывает достаточно (я могу использовать переменную окружения TF_BUILD_SOURCEGETVERSION, когда сборка запускается слиянием). Однако иногда будет несколько наборов изменений, которые связаны со сборкой в TFS.Получить изменения, связанные со сборкой

Использование номера сборки, как мне получить список изменений?

источник

2015-02-23 Dave Johnson

Это для целей выпуска? Если это так, вам будет намного лучше, если использовать SSDT и опубликовать схему базы данных во время процесса выпуска. –

@ DanielMann Да, он должен запускаться как сценарий Post-Build. Возможно, нам было бы лучше, но процесс (и DBA) диктует, что мы должны обрабатывать развертывания SQL (изменения модели, обновления данных, изменения proc и т. Д.) С помощью набора сценариев развертывания, созданного вручную (по DBA). DBA использует файлы, которые мы предоставляем в сетевой папке, для создания сценариев. Прямо сейчас команда должна вручную собрать список, и они вручную копируют файлы. Я ищу только для устранения нашего ручного процесса, потому что это будет намного проще, чем изменить способ работы DBA. –

Вам нужно использовать свой номер сборки, чтобы найти предыдущий номер сборки. После этого у вас будет и начальный набор изменений (от предыдущей сборки) до текущего набора изменений (текущая сборка).

Затем вы можете пройти разрыв с API и найти все промежуточные изменения.

источник

2015-02-24 05:25:19

Таким образом, я сделал это в своем последнем взаимодействии, по сути, мы решили его, выполнив получение всех связанных с SQL файлов. КАЖДОЙ сбор и создание файла csv, содержащего информацию о каждом файле, имени, версии и, самое главное, и MD5 хэш файла. Затем при каждом развертывании мы создаем/обновляем/вставляем в специальную таблицу развертывания в нашей БД весь SQL «запускаем» против этой БД. Тогда наш скрипт сборки действительно создает файл csv, но наш скрипт развертывания обладает интеллектом и проверяет, не изменилось ли что-либо в файле csv и целевой базе данных, и применяется только к изменениям (новый SQL, изменился SQL с новым MD5). Поэтому мы по существу используем два сценария. Я не могу поделиться сценариями, но у вас есть идея. Также я бы посмотрел на эту статью Александра Automating SQL Server Database Deployments: Scripting Details, где он много рассказывает о миграции db.

источник

2015-02-24 15:04:35 Etienne

Получить изменения, связанные со сборкой

ответ

Смежные вопросы