0

Моя команда разработчиков находится в процессе реализации ветвления и слияния в TFS. Наше программное обеспечение содержится в одном решении, в котором реализовано множество проектов. Один из этих проектов содержит все сценарии SQL, чтобы наши базы данных были версиями.Автоматическое переименование файлов во время слияния TFS

У нас возникли проблемы с тем, как обращаться с проектом базы данных во время слияния. Например, всякий раз, когда разработчику необходимо внести какие-либо изменения в базу данных (добавить/удалить сохраненный процесс, создать таблицу, добавить индексы и т. Д.), Мы создаем файл сценария. Каждый файл получает имя с номером версии. Например, если последний файл скрипта, который был проверен, называется 4.1.0.1, я бы назвал мой новый скрипт 4.1.0.2. Мы используем эти имена файлов в соответствии с версией программного обеспечения с соответствующей версией базы данных, которую нужно запустить.

Скажем, я создаю ветку от нашей основной ветви кода, чтобы сделать новую функцию. Я делаю все кодирование, и я поместил все мои изменения SQL в один файл сценария и добавил его в проект БД. Очевидно, я мог бы просто объединиться с главной ветвью кода в мою новую ветку, чтобы убедиться, что у меня есть последний список SQL-скриптов, поэтому я мог бы назвать это правильно. Проблема в том, что новые файлы сценариев добавляются несколько раз в течение дня, и мы думаем, что у нас будет тонна конфликтов слияния с именованием скриптов.

Я хотел бы как-то автоматизировать это, поэтому разработчик может просто добавить скрипт с некоторым случайным именем, и во время слияния есть крючок или событие, которое будет определять, какие файлы являются новыми для основной базы кода, а также как правильно назвать эти файлы, чтобы разработчикам не пришлось об этом беспокоиться. Например, я могу просто создать новый файл с именем «new_script.sql», и когда я сгенерирую его обратно в ветвь основного кода, он будет переименован в 4.1.0.2.

Раньше я использовал такие инструменты, как RoundHouse, чтобы позаботьтесь обо всех версиях SQL, однако в моем текущем задании мы используем Sybase SQL Anywhere 10, и мне не удалось найти что-то похожее на RoundHouse, которое будет работать с Sybase.

Может ли кто-нибудь указать мне в правильном направлении, как автоматизировать задачу во время слияния TFS? Я предполагаю, что это можно сделать с помощью PowerShell, но я обеспокоен тем, что большая часть разработчиков не знакома с PowerShell, и я надеялся, что смогу автоматизировать эту задачу, если разработчику не придется покидать окно проводника команды.

Любая помощь очень ценится!

Спасибо!

ответ

0

Я думаю, что вы абсолютно правы, что столкнетесь с конфликтами именования, если будете продолжать использовать эту стратегию и вводить ветви.

Я думаю, что у вас есть два варианта:

  1. При добавлении этих файлов на ветке, добавить их Префиксальные с именем ветви. Например. branch_0.1.sql и branch_0.2.sql. Затем, когда вы объедините свою ветку обратно в багажник, вам придется переименовать их в правильное имя. Вы могли бы написать программу, чтобы сделать это для вас, и было бы довольно просто. Чтобы сделать это проще, вы можете создать только один файл SQL на каждую ветку и просто добавлять к этому одному SQL-файлу. Тогда даже вы сливаете это очень простой процесс.

  2. Откажитесь от файлов с версией. Tfs - контроль версий. Существует не так уж важно, чтобы версия файлов самостоятельно. Мы используем проекты базы данных Visual Studio для нашего управления версиями баз данных, и это работает безупречно. Думаю, вам нужно будет что-то изменить в своей стратегии развертывания, если вы измените это.

Надеюсь, это поможет.