部署.NET Web应用程序的最佳实践

Question

我在一个认为将代码直接从Team Foundation Server（TFS）部署到生产环节的地方工作。几乎不可能让他们相信这是一个坏主意，因为他们只能责怪程序员检查他的代码。

TFS对于它所做的事情并不总是透明的。你可能知道。并且可能无意中检查您的更改。

我想以比这更好的东西卖掉它们，除了我不知道它是什么。我不能使用正确的Google关键字，因为当页面或链接谈论部署时，它不会将部署作为软件周期的一部分进行讨论。 IE，＆＃34; .NET部署的最佳实践＆＃34;将讨论从您的项目，IIS设置等发布。

必须有更好的方法。代码冻结？代码分支？是不是有一些方法可以同时部署部分应用程序而不是整个网络应用程序？

Answer 1

部署的最佳做法（imo）

• 已采取数据库/网站备份
• 一切都是脚本化的 - 没有手动连接到数据库以添加额外的列
• 您已经在暂存区域（在实时数据的副本上）测试了部署
• 您有回滚计划（即使它只是还原数据库）
• 部署是可重复的 - 它应该包含根据该版本设置站点所需的所有文件，而不仅仅是更改的文件。
• 您向每个环境发布完全相同的构建，从分段到生产时不构建新版本的代码
• 从构建服务器而不是从单个开发人员计算机上发布，无论发布者是谁，它都应该是相同的。
• 你释放的变化越小，可能出错的越少，释放应该经常发生并且应该很容易

从技术上讲，只要您在整个过程中对代码进行充分测试，直接从TFS发布到生产就没有任何问题。

许多开发人员梦寐以求的理想环境就像

• 开发人员检查代码
• 构建服务器抓取代码，确保构建，运行所有单元测试
• 构建服务器将代码部署到测试计算机并运行自动化测试
• 如果一切都过去了，那么代码就会被推送

当然，没有多少开发公司有足够的单元/自动化测试，他们觉得安全快速推动它的生存。

TFS Deployer 在后台完成了大量工作，大多数人甚至不必知道它不是TFS的功能。它还可以与所有构建和测试功能集成在一起，确保代码质量始终良好。

代码冻结是一个坏主意，您不希望您的开发资源在不允许触摸代码的情况下停机。相反，您应该考虑适合您的分支策略。那里有很多，但这里有我能想到的主要内容：

• 基于质量 - 您为Dev保留了一个分支，一个用于分段，一个用于生产。当代码通过每组测试时，您手动将其更改集合并到下一个分支中。这也意味着您可以轻松修复生产中的错误，而无需发布尚未准备好的新更改

• 基于版本 - 您在主分支中执行所有开发，当版本完成时，您将其分支并仅触摸该分支以执行错误修复。这也允许您在不发布新的未经测试的代码的情况下对实时（或您可能支持的任何其他版本）进行错误修复。

• 基于功能 - 所有开发都在新分支中进行，一旦完成，它就会合并回主干。行李箱是唯一被释放的分支。

我建议不要分支，直到需要分支。很多人不知道你可以从特定的变更集/日期分支。这意味着如果您知道发布的时间，您可以在需要应用错误修复时将其分支，然后将其合并回主干。当然，在发布时需要更多的纪律，因为您需要始终知道服务器上运行的变更集。

当然，我可能会错误地阅读您的帖子，也许您并不是要求部署最佳实践，而是真正询问如何让您的经理相信在他们上线之前需要对其进行测试。如果是这样，你有一个更大的问题。开发人员（通常）不是好的测试人员，当然不是他们编码的东西。如果您没有专门的测试人员和流程来执行单元测试和自动化测试，那么您应该首先考虑这一点。

Answer 2

您是否看过TFS部署人员？我在我们的一个客户身上使用它，它的工作非常出色。它的工作原理是捕获和处理TFS在TFS中构建质量变化引发的事件。捕获事件后，TFS部署程序服务将为您提供删除位置的路径以及更改构建质量的用户。用户身份使您有机会围绕它构建安全性和权限矩阵，如果您想要获取部署者并部署构建，则放置位置很方便。如果完全支持power shell，cmd和wix。看看这篇博文=＆gt; http://geekswithblogs.net/TarunArora/archive/2011/05/21/tfs-deployerndash-automate-deployments.aspx我正在使用TFS部署者部署Web和数据库，完全自动化并记录。如果我能提供任何进一步的细节，请告诉我

HTH 干杯，塔伦