Как отследить развернутые файлы

Question

В настоящее время мы ищем лучшие альтернативы нынешнему способу нашего развертывания. Я ищу любой совет. Знайте, что текущая система, которую мы используем, единственная, которую я когда-либо использовал. Мы несчастны, потому что это очень подвержено ошибкам (вы поймете, что я имею в виду в деталях). Также имейте в виду, что мы переходим с SourceSafe на TFS.

Наша компания:
Я работаю в пенсионной системе. Большая часть нашего кода используется для внутренних целей, хотя некоторая часть используется на нашем внешнем веб-сайте.

Архитектура:
Большая часть нашего кода основана на 2 уровнях. Наша схема базы данных довольно большая ... у нас есть 6000 хранимых процедур и 1000 таблиц. Разработчики разрабатывают как код .net, так и хранимые процедуры.

Как работают наши текущие развертывания:
В SourceSafe у нас есть 3 корневых папки $ / Dev, $ / Test, $ / Prod, которые соответствуют базам данных dev / test / prod.

У нас есть собственное приложение для отслеживания проблем. Мы будем работать над всеми проблемами в ветке $ / Dev. Затем мы создадим документ, в котором каждый файл, который мы изменили, вместе с исходной безопасной версией # файла (файлы хранимых процедур / .sql помещаются в исходный код безопасности, как и все остальные). Они будут переданы специалисту по развертыванию, который переместит все файлы из $ / dev в папки $ / test. Другие сотрудники по развертыванию затем создадут все наши приложения и выполнят все изменения хранимых процедур в тестовой базе данных. Проблема будет проверена назначенным тестировщиком из нашего сообщества пользователей, и как только она будет завершена, файлы будут перемещены из $ / dev -> $ / prod. У группы по развертыванию есть электронная таблица, чтобы убедиться, что ни один файл не будет преобразован в $ / Prod, если он не подписан.

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

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

Answer 1

Я бы предложил иметь три ветви в TFS: DEV / TEST / PROD.

Вместо того, чтобы создавать документ для отслеживания всех изменений в DEV, просто позвольте TFS сделать это за вас.Когда вы будете готовы продвигать свои изменения в TEST, просто выполните слияние с DEV -> TEST (это называется языком обратной интеграции в TFS).

Если вы хотите иметь возможность работать над несколькими «проблемами»сразу в DEV и только для продвижения изменений, связанных с определенной проблемой, вы можете использовать ветви функций, которые существуют как дочерние элементы ветви DEV.Только когда проблема завершена, она перемещается в ветку DEV.Если вы используете эту стратегию ветвления, вам может не потребоваться отдельная ветка TEST, поскольку ваши тестировщики могут просто работать с DEV, который включает только завершенные проблемы.

Для развертывания совет зависит от того, что именно вам нужно развернуть.Поскольку вы упомянули только базы данных, я сосредоточусь на инструментах, доступных для этого.Вы можете создать проект базы данных в Visual Studio, который представляет схему базы данных и данные в определенный момент времени.Это источник контроля, как и любой другой проект VS.Когда ваша группа по развертыванию желает развернуть ее, они будут делать это либо с помощью Visual Studio, либо с помощью инструмента командной строки (гораздо более распространенный для персонала типа операций).Инструментарий анализирует проект БД в VS, сравнивает его с действующей базой данных и генерирует сценарий sql, который можно выполнить для действующей базы данных, чтобы он соответствовал проекту VS.Весь этот процесс может быть довольно легко автоматизирован (в идеале в сборке TFS).

Моя цель состоит в том, чтобы определить сборку TFS, которая запускается в любое время, когда код проверяется в TEST (или DEV, если используются ветви функций).Это автоматически создало весь ваш код и развернуло все базы данных и другие артефакты в соответствующей среде тестирования.