部署建议

Question

我想知道是否有人可以就我们在我工作的地方使用的当前部署程序提供任何建设性的反馈：

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

我认为目前缺少的东西是适当的单元测试和集成测试（最好使用 NUnit 和 selenium 之类的东西），但我想看看社区的想法。

Answer 1

您可以使用 TFS 将其压缩为单个源代码控制实例，并将您的代码分支以进行发布构建。

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

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

当识别出质量合适的构建时，也可以将 TFS 服务器配置为直接从其存储库对标记的构建进行实时推送。

所有这一切的好处是，开发团队使用与 QA 团队相同的存储库，因此能够直接向他们提供“任务”/错误报告，而且服务器也将所有手动部署的东西都取出你的架构。

MSBuild 还包括 MStest，在我看来，它对自动化测试并没有那么糟糕，因为它向项目经理报告（再次返回给开发团队和）有关错误和任务的信息，它还提供开箱即用的敏捷性准备好了。

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

...

开发人员通常在他们的解决方案的 PC 上运行自己的“副本”，除非解决方案非常复杂，在这种情况下，在链接到主域源控制服务器的单独域上的完整虚拟化开发环境可能是要走的路.

虽然取决于解决方案的复杂性。