C# 部署建议

我想知道是否有人能对我们在工作中使用的当前部署过程提供任何建设性的反馈：

我们在单独的Mercurial存储库中有三个代码副本：Dev、PP Pre-Production和Live。在Dev上进行更改，推送到PP进行用户验收测试，然后在验收后推送到Live。 构建是使用TeamCity创建预编译版本完成的，更改不是手工完成的，所有内容都必须进入源代码管理。构建作为zip档案在TeamCity中作为工件提供。类库是按需构建的，并作为依赖项链接到主构建中，Bin文件只保存在源代码管理中，而我们没有源代码。 使用RemoteDesktop手动将构建复制到实时环境中，并解压缩。web.config文件在不同版本之间保存，并在需要时手动编辑。实时密码等不保存在源代码管理中

---

我认为目前缺少的是适当的单元和集成测试，理想情况下使用NUnit和selenium之类的工具，但我想看看社区的想法。

您可以将其压缩为一个带有TFS的源代码管理实例，并将代码分支用于发布版本

从那里，构建可以自动运行、测试，并部署到每晚/每周的测试中。 然后，您的QA质量保证团队将在自动化测试的基础上进一步测试构建，并批准或拒绝构建

如果构建质量合适，QA团队可以通过visual studio或构建通知工具栏应用程序或直接在tfs门户中设置构建质量

当识别出具有适当质量的构建时，还可以将TFS服务器配置为直接从标记的构建上的存储库进行实时推送

所有这一切的好处是，开发团队使用与QA团队相同的存储库，因此能够直接向他们提供任务/bug报告，但服务器也会在您的体系结构中删除所有手动部署的内容

MSBuild还包括MStest，在我看来，MStest对于自动化测试来说并不坏，因为它会再次向开发团队和项目经理报告有关bug和任务的信息，而且它还可以开箱即用

不利的一面。。。 如果您对msbuild没有信心，那么设置会有点复杂和繁琐，但是如果您习惯于MS开发环境，那么这并不是一个巨大的学习曲线

开发人员通常会在其pc上运行自己的解决方案副本，除非该解决方案极其复杂，在这种情况下，在一个单独的域上建立一个完整的虚拟化开发环境，链接到主域资源控制服务器可能是一条路要走

但这取决于解决方案的复杂性