Управление файлом проекта SSDT должным образом с контролем версий (* .sqlproj)

Question

У нас есть постоянная проблема с XML-проектом проекта (* .sqlproj). Если файлы добавлены/обновлены/изменены, то он автоматически добавляет/удаляет записи в некоторых неожиданных местах. После этого у нас большие проблемы, слияния, когда кто-то тоже меняет этот файл.

Мы пришли к выводу, что мы можем сортировать его перед регистрацией. Мы будем сортировать по алфавиту, и в этом случае инструмент слияния поймет его намного лучше.

Итак, мои вопросы будут:

1. Можно ли переставить файл sqlproj как-то перед каждым заездом? Может быть, есть некоторые варианты/инструменты, которые уже делают это?
2. Есть ли другие способы сделать жизнь разработчиков проще?

UPDATE:

Еще раз я получил ту же проблему. Файл sqlproj был изменен 3 раза, и я хочу слить на производство только последнее изменение, другие 2 еще не протестированы. в инструменте слияния у меня есть возможность добавить все эти 3 новые объекты или оставить его без изменений. Я не в состоянии выбрать только последнее изменение ...

Пример:

1. developerA создал TABLEA и проверили в;
2. developerB получил последнюю версию ветви dev, создал tableB и зарегистрировался;
3. developerC получил последнюю версию ветви dev, создал tableC и зарегистрировался. DeveloperC проверил код и готов к работе. Он пытается объединить свой код с QA и получить конфликт, в котором у него есть возможность только со всеми изменениями.

Answer 1

1 - какой источник управления вы используете? Никакой контроль источника, который я знаю, не понимает контекст файлов sqlproj, но это обычно не проблема.

2.a - Это не должно быть проблемой, с которой вы постоянно сталкиваетесь, регулярно ли вы проверяете/выходите? Я бы только ожидал увидеть проблемы, если разные разработчики делают масштабные изменения в проектах, а не проверяют/проверяют до и после.

2.b - Возможно также, что вы не сливаетесь правильно, если вы берете оба набора изменений, то это нормально нормально.

ed

Answer 2

Я понимаю сценарий, в котором вы работаете, очень хорошо. Обычно это происходит, когда у вас есть несколько рабочих потоков, происходящих в контексте одного репозитория, и у вас нет общего расписания рассылки (так как во всех случаях работа будет проходить одновременно с QA и PROD одновременно).

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

1. Заблокируйте каждую среду, пока все не будет способствовать совместному использованию. В большинстве случаев это нереалистично.

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

3. Гибридный подход ... Не используйте источник управления в Dev до тех пор, пока он не будет готов к тестированию. Затем либо сделайте вариант № 1 или 2 оттуда.

4. Создайте более гибкую экосистему, которая может развернуть среду для каждой ветви Feature, чтобы демонтировать/протестировать другие (или, по крайней мере, распределить/повернуть достаточно между разработчиками для достижения той же цели). Как только он будет принят. Это то, к чему мы сейчас стремимся, но создаем инфраструктуру и процесс, когда у вас есть тонна взаимосвязанных баз данных и приложений, которые их разделяют, - это немного сложно сказать (особенно в мире Microsoft).

Любом надеется, что это поможет ...