部署建议

时间:2010-07-09 09:52:50

标签: c# asp.net deployment

我想知道是否有人可以提供有关我工作的当前部署程序的任何建设性反馈:

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

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

1 个答案:

答案 0 :(得分:0)

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

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

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

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

所有这一切的好处是开发团队使用与QA团队相同的存储库,因此能够直接向他们提供“任务”/错误报告,但服务器也会将所有手动部署内容你的建筑。

MSBuild还包括MStest,在我看来,对于自动化测试并不是那么糟糕,因为它报告(再次回到开发团队和项目经理关于错误和任务的信息),它也开箱即用准备好了。

不利方面...... 如果你对msbuild不自信,那么设置有点复杂和繁琐,但如果你习惯于MS dev enironment,这不是一个巨大的学习曲线。

...

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

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