Как правило, рекомендуется использовать тот же набор файлов сборки, который вы сгенерировали для развертывания тестовой среды, так и для развертывания prod, поскольку это единственный способ гарантировать, что то, что вошло в сборку, будет согласованным (т.е. между двумя сборками что-то могло быть установлено на сервере сборки, или ваша VCS может вернуть немного другой набор файлов исходного кода).
Лучше всего это достигается в TeamCity с использованием артефактов сборки, которые собирают выходные данные ваших сборок в специальную область хранения, позволяя их перенести в другую конфигурацию сборки для дальнейшего использования. Больше информации в документах TeamCity http://confluence.jetbrains.net/display/TCD6/Build+Artifact
Что касается ваших конфигов, рассмотрите возможность использования конфигурационных преобразований. Это позволяет вам иметь свой вариант Web.config для каждой целевой среды с различными строками подключения, константами среды и т. Д. Подробнее о MSDN http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
Если вы действительно намерены использовать TeamCity для развертывания в своей производственной среде, вы можете рассмотреть возможность блокировки их с помощью разрешений TeamCity, чтобы только ограниченная группа имела доступ для запуска этих конфигураций сборки (в нашем магазине это фактически требование обеспечить разделение обязанностей между командами Dev и Ops). В качестве дополнительной меры предосторожности, установите отдельный агент сборки только для ваших сборок Prod и держите его отключенным до тех пор, пока он вам не понадобится (предотвращает случайный запуск конфигурации сборки prod ... да, я был там вздох ).