2010-07-09 73 views
1

我想知道如果有人能提供有关当前部署程序的任何建设性的反馈意见,我们使用,我的工作:部署建议

  • 我们有单独的Mercurial库的代码的三个副本:开发,PP(预 - 制作)和Live。对Dev进行更改,推送到PP进行用户验收测试,然后在接受后推送到Live。
  • 构建是使用TeamCity创建预编译版本完成的,所做的更改不是手工完成的(所有内容都必须进入源代码管理)。这些版本以TeamCity中的工件作为zip存档提供。类库是按需构建的,并作为依赖关系链接到主构建中,Bin文件只保存在没有源代码的源代码控制中。
  • 使用RemoteDesktop手动将构建版本复制到实时环境中,并解压缩。 web.config文件不会被构建以便在需要时手动编译和编辑(实时密码等不在源代码管理中)

我认为缺少的当前事情是正确的单元和集成测试理想情况下使用NUnit和硒之类的东西),但我想看看社区的想法。

回答

0

您可以使用TFS将其压缩为单个源代码控制实例,并将代码分发给发布版本。

从那里构建可以自动运行,测试和部署到“测试”每个夜晚/星期。 然后,您的QA(质量保证)团队将测试构建(在自动化测试之上进行进一步测试),并批准或拒绝构建。

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

当确定合适质量的构建时,TFS服务器也可以配置为直接从其存储库中对标记的标记构建进行实时推送。

所有这一切的优势在于,开发团队与QA团队使用相同的存储库,因此能够直接向他们提供“任务”/错误报告,而且服务器还取出所有手动部署的东西在你的架构中。

MSBuild还包括MStest,在我看来,它并不是所有的自动化测试都不好,因为它报告(再次回到开发团队)并向项目经理提供关于错误和任务的信息,它也出来了敏捷准备。

不好的一面... 如果你对msbuild没有信心,有点复杂和烦琐的设置,但是如果你习惯了MS dev环境,这不是一个巨大的学习曲线。

...

开发商一般都有自己的“副本”在他们的解决方案,除非该解决方案的PC运行的是极其复杂的这种情况下,在一个单独的域全虚拟化的开发环境链接到主domainssource控制服务器可能是要走的路。

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