将Web应用程序直接从SVN部署到生产环境是否可以接受

题

是否有合理的理由不使用SVN进行生产部署，或者这仅仅是个人喜好而没有针对SVN的真实案例？

背景

我的工作场所具有在SVN中标记发布的文化，然后使用（svn co或svn switch直接包括）将这些发布直接部署到各种Web服务器。

我个人对此有一个问题，因为我相信如果不使用构建和部署脚本，某种形式或自动部署，就会丢失集成环境设置，因为它们没有文档说明。然而，不仅如此，我有一种直觉，认为这样做可能存在隐藏的危险，而这种危险尚未被抬起头来。

我已经向负责将代码部署到我们的各种环境（阶段，预生产，生产）等中的运营人员提出了自己的担忧。他们的观点几乎是到目前为止效果很好，没有理由进行更改。

编辑：

我的意思是关于构建和部署：

例如，如果开发人员需要为特定环境添加web.config设置。Web.config通常不保存在svn中，因此无需任何形式的自动构建脚本即可手动更新这些文件。因此，如果它们丢失或OPS忘记为发行版在web.config中添加字段，则可能会遇到问题。

可以使用XMLPoke自动生成适合于特定环境的web.config的构建脚本非常理想，因为您有一个可版本化的脚本，该脚本记录了每个环境所需的所有更改。

当前的构建和部署方法

对于有问题的项目，开发人员可以手动构建发行版，而其他项目则可以使用NANT或MSBuild将构建步骤自动化。

对于大多数项目，数据库迁移是通过DB脚本，迁移脚本（Migrator.NET）或CMS程序包进行的。

CI通常是由Team City在每次签入的基础上完成的，我们有一个代码审查过程，所有票证都在分支机构中完成，然后在进入中继线之前进行同行审查，以确认其有效性和正确性/质量（运作良好）。

但是，实际的代码部署几乎总是通过SVN来进行，或者是通过签出带标记的版本，或更通常是通过SVN Switch来进行。在我们使用存储库作为部署过程的一部分时，这让我感到奇怪。

配置通常不会经常更改，配置文件中唯一会发生的事情就是特定于环境的信息。其他所有内容都在数据库中。

不要误会我的意思，这行之有效。但是，我想尝试推动自动化的构建和部署。我已经在Rails和Capistrano以及用于Cygwin，Nant和SSH的个人项目中使用了它。

更重要的是，我需要非常具体的有效参数来使我的同事转变为使用自动生成和部署。

还是没有真正的有效论据反对使用SVN专门部署到生产环境？

根据我的经验，既有优点也有缺点：

优点：

• 有时，您在生产服务器上进行了紧急修补程序，然后可以直接从那里重新签入它们。（尽管从理论上讲，出于安全性考虑，最好使用对生产服务器上的存储库的只读访问权限。）

• 简便性：您可以快速交付，尽管正如此处提到的其他人一样，切换到更新脚本方案也很容易。

缺点：

• 在您svn up和数据库更新期间，系统可能会变得不稳定。对于流量较高的网站，这意味着某些用户充其量只能打出错误消息，页面破裂或空白页。好吧，这就是我们在各种社会服务中经常看到的。但是，良好的服务会在某种意义上“原子地”执行，即在更新期间将系统置于维护模式。（您打破了reddit！）

• 冲突：解决生产服务器上的突然冲突是一个可怕的主意：同样，服务在修复时变得不稳定。

• 生产服务器上无关的文件可能属于您也可能不属于您，尽管您当然可以通过在存储库中检出正确的子树来避免这种情况。

• 安全性：合法或不合法地访问您的生产服务器的人，也可以访问您的存储库，可能还包括其他产品，并且还可能具有写访问权限！将您的内部SVN服务器全面向外界开放是一个坏主意。您的源存储库应在公司防火墙之后。

• 无论如何，都会有更新脚本，例如用于更新数据库结构，管理cronjobs等，那么为什么不拥有一个能够完成所有任务的脚本呢？-即提取最新的预打包版本，切换到维护模式，更新源，运行特定于版本的脚本等。

编辑：对于那些仍然使用SVN方案的用户，请不要在您的apache配置中忘记这一点：

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

我在工作中设置了一个CI服务器，假定单元测试成功通过，它会自动创建我们的安装程序。自完成设置以来，它花费了整整一天的时间，为我节省了很多。

如果在配置发布/安装程序/生产网站时有任何手动过程，那么您将始终节省自己和公司的时间。从您的问题来看，这似乎很适合您，看起来您的设置过程中有手动配置步骤。

作为参考，请参阅Joel本人谈论的有关单击创建过程如何在短期到中期节省您的时间。

确保在SVN上具有适当的检入控件。例如，考虑一下-

• 已签入功能以发布
• 将代码部署到暂存中，质量检查工作
• 错误已修复，需要另一轮测试（无论如何在您的团队中运行）
• 前产品的同上
• 部署到生产

如果在预制作阶段之后有人不小心进行了签入，就有可能破坏某些内容。如果这是受控的-除错误修复外，预生产期间不允许签入-我看不到任何风险。

更新：如果您不检入配置文件，则可能会遇到问题。除了“请尽快做！”之外，我真的不能为此提供任何建议。

只要存储库之外没有任何东西，就可以了。实际上，我认为不应在项目的前几个月花时间在部署工具上。因为会有太多的部署，没有足够的客户来困扰正式发布过程。

但是，一旦该项目成立了大约一年，就值得考虑投资部署工具。简单的原因是

• 业务不断增长，因此您计划将其托管在多个服务器上
• 在特定的环境中可能存在错误，并且您没有任何地方可以复制该错误。没有tar-untar-forget_about_home_for_a_week流程，没有简单的方法来进行设置。
• 有人可能会破坏构建。谁破坏了构建

如果要说服他们，请他们设置另一台服务器以进行内部测试或质量检查。