用于生产环境的 SVN 结帐或导出？答案

【问题标题】：SVN checkout or export for production environment?用于生产环境的 SVN 结帐或导出？
【发布时间】：2008-10-06 16:31:09
【问题描述】：

在我正在进行的一个项目中，我们在开发团队之间进行了持续的讨论 - 生产环境应该部署为 SVN 存储库的签出还是导出？

开发环境显然是一个结帐，因为它不断更新。对于生产，我个人是检查主干，因为它使将来的更新更容易（只需运行 svn update）。然而，一些开发人员反对它，因为 svn 创建具有组/所有者和 svn 进程权限的文件（这是在 linux 操作系统上，所以这些事情很重要），并且在生产中也有 .svn 目录似乎它们有点脏。

另外，如果是结帐 - 如何在不包含开发中代码的情况下将单个功能推送到生产环境？您是否为每个功能使用标签或分支？有其他选择吗？

编辑：我可能不太清楚 - 要求之一是能够不断地将修复推送到生产环境。我们希望避免仅仅为了推送关键修复而进行完整构建（这比简单更新需要更长的时间）。

【问题讨论】：

您听起来好像正在远离分支和标记生产版本。为什么？
我已经编辑了我的问题以进一步解释
我想我不明白什么是“Critical Fix”，以及为什么它没有像完整构建那样受到同样的关注和尊重。或者它是否具有相同级别的 QA 并且您的构建需要很长时间？我不明白这个问题。
构建需要几分钟时间，而且我不希望每次我想将关键修复推送到生产环境时网站都会离线几分钟。我希望这能说清楚。
网站为什么会下线？您可以从 SVN 结帐到生产位置执行“构建然后移动”操作吗？如果是这样，这是否会消除尝试从主干管理生产版本的危险？

标签： svn deployment

【解决方案1】：

The Subversion FAQ 似乎提倡将部署作为结帐，使用提交后挂钩脚本自动更新。他们通过在 httpd.conf 中添加以下内容来阻止 Apache 导出 .svn 文件夹（可能是个好主意）：

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

我自己对 svn 非常陌生，但也许您可以在创建新标签时触发挂钩脚本。这样，当您准备好更新实时站点时，您只需将最后一次更改提交到主干，创建新标签，脚本就会使用 svn update 更新您的实时站点。

【讨论】：

经过进一步调查，似乎没有一种明显的方法可以在创建新标签时触发挂钩脚本。
这个真的值得一看：stackoverflow.com/questions/4159104/…

【解决方案2】：

我一直在为此苦苦挣扎，我想我终于决定结帐了。是的，那里有多余的垃圾，但是...

导出不考虑已删除的文件（除非您的解决方案是删除目录中的所有内容然后导出，我认为这会更糟）。 Checkout 将删除已删除的文件。
结帐速度更快。时期。更少的文件被更新意味着更少的关闭/转换时间，并且导出会下拉并覆盖所有内容，而不仅仅是需要更新的文件。

并不是说它对每个人都有效，但是这两件事影响了我的决定。祝你的决定好运。

【讨论】：

【解决方案3】：

恕我直言，您应该创建一个分支/标签，其中您拥有用于生产的开发环境的（所需）子集。有人应该手动或使用脚本自动维护它。然后，您应该导出（而不是结帐）。增量更新不是问题，除非您在生产环境中更改文件并且不希望这些文件被覆盖。

只要我的 0.02 美元

【讨论】：

如您所见，许多人不同意您的说法（导出而不是结帐）。你能否更清楚地解释你为什么这么说。我还发现能够更新而不是删除所有内容并再次导出所有内容更方便。所以我正在寻找任何好的出口论据，但没有找到。唯一担心的是安全性，但在我看来 .htaccess 会很好地处理这一点。

【解决方案4】：

没问题 - 出口。

您不会进行更新，因此没有理由结帐。你只是在部署垃圾。

我想说任何环境都应该只是一个出口；您仅在开发时在本地使用结帐。当然我们也在使用构建脚本，所以更新部署就像运行脚本一样简单。

就开发中的代码而言，为正在完成的任何工作创建分支。只有在准备好部署到开发环境时才提交到主干。

【讨论】：

如您所见，许多人不同意您的说法（毫无疑问）。您能否更清楚地解释为什么这对您来说没有问题。我还发现能够更新而不是删除所有内容并再次导出所有内容更方便。所以我正在寻找任何好的出口论据，但没有找到。唯一担心的是安全性，但在我看来 .htaccess 会很好地处理这一点。
首先，我总是做 Web 应用程序而不是网站，而且我不部署代码文件（将它们构建到 dll 中并部署到 bin）。这更加清洁和安全。而且由于我的网站是这样的，我绝对不想让 SVN 连接并更新文件。其次，正如我上面所说，首选方法是使用构建脚本，所以我的流程是-- 1）从 SVN 导出代码到构建位置 2）执行脚本来构建 3）构建的最后一步是将编译后的版本复制到站点位置。这样，无论构建多长时间，站点都只会在文件副本的长度内停机。
感谢您的额外解释！

【解决方案5】：

我会研究一些部署软件，比如 Capistrano（它是一个 ruby 程序）

如果您要使用自己的解决方案或手动操作，我个人会使用导出主干的标记副本而不是仅导出主干。

【讨论】：

【解决方案6】：

我将其部署为副本。当然不是手动的。

我使用“make”和“checkinstall”。我创建了一个小的 Makefile，它使用系统命令“安装”将所有需要的文件复制到 Web 服务器上的相应目录，并且我有将在服务器上运行的预安装和安装后 shell 脚本。

当部署时间到来时，我只需运行“checkinstall”，它会创建一个包（RPM、DEB 或 TGZ，具体取决于我所针对的 Linux 发行版）。我使用 Linux 分发包管理器（rpm、dpkg、pkgtool）提供的常规工具安装它。当然，如果你也想跟踪依赖关系，你可以使用 yum、apt-get 等。

如果您想分发新版本的网络应用程序，这真的很容易。到多个目标服务器。卸载、恢复到旧版本等操作非常简单，因为您为部署的每个版本都有一个现成的包。

如果您使用一些需要编译的东西，这可能不适合您的“经常推送”策略。但是，对于编写脚本的东西（比如我做的 PHP），在我的机器上创建一个包（大约 300 多个 PHP 文件）大约需要 20 秒。几乎可以在任何目标系统上安装它。

为了将“用于发布”的代码与“开发中”的代码分开，我使用了分支。使用 Git，这真的很容易，因为分支既便宜又快速。

【讨论】：

20 秒是相当长的停机时间...每次我想将修复推送到生产环境时，我不会让网站离线 20 秒。
并非如此。当新文件被复制过来时，旧的东西仍然存在。实际上，您甚至可以设置 postinstall-script 以将所有文件设置在不同的目录中，并在复制完成时将其切换为 live 目录。与 'svn export' 类型的部署没有区别。

【解决方案7】：

就我个人而言，我一直对这个问题的解决方案持怀疑态度，我更喜欢在我的生产环境中没有“.svn”目录，它很脏但与此同时，大型 Web 应用程序的导出非常繁琐（特别是如果使用一些第三方“组件”，如 Extjs、FCKeditor 等）。

我认为目前没有“杀手级解决方案”。

【讨论】：

【解决方案8】：

让我看看..... ln -s ?可以用来做什么？

/var/www/www.my-prod-site.com/public/
/var/www/www.my-prod-site.com/builds/Rev 1/
/var/www/www.my-prod-site.com/builds/Rev 2/
/var/www/www.my-prod-site.com/builds/Rev 3/
/var/www/www.my-prod-site.com/builds/Rev 99/

svn 导出到您的构建目录......从 /public 复制任何配置文件，这是您到以前版本构建的符号链接，然后只需将符号链接从公共转移到指向您的新构建目录.与我在此处发布的任何内容相比，它离线所需的时间更少，而且它还可以更快地返回，除非您每次都通过更改表来 fckp 您的数据库。

【讨论】：

【解决方案9】：

这里有一些意见 -

.svn 生产环境文件脏了？如果 .svn 目录完好无损并且没有损坏，那么它们远非肮脏，它们实际上是救命稻草。为了安全起见，您可以告诉 apache 阻止浏览它们。

结帐还是导出？我的方法... 我肯定会使用标签和分支——将生产服务器附加到主干并祈祷没有人在有人将错误代码提交到主干以查看它在 DEV 上的作用后立即运行 svn 是很危险的。我有一个可重复使用的标签（比如 _production 和 _staging），在我的设置开始时，我将每个标签签到匹配的服务器。然后我锁定所有访问以修改实时和登台服务器的内容。此后，DEV 服务器被绑定到主干头。当代码对于 QA/staging 足够稳定时，我们创建一个标记并将其重命名为 _staging 以允许 staging 服务器在看到该标记发生更改时与其同步（脚本运行 'svn up'）。一旦我们对 _staging 感到满意，我们将其重命名为 _production，这会使代码部署到实时服务器。或者，您可以创建具有不同名称的标签/分支，并使用“svn switch URL”将服务器指向新的标签/分支（固定点）。以上所有使部署变得非常容易而无需停机，如果需要回滚，您可以快速重命名存档的前标签或使用 'svn switch OLD_URL' 立即撤消新更改，而无需担心每个小文件和行更改。

权限和所有权如果您了解并知道文件的权限应该是什么，则可以在每次部署后运行脚本以将 CHOWN 和 CHMOD 设置为您想要的。

恐惧与知识我听说很多害怕的人排除了生产服务器上存在 SVN。反面其实很可怕。您如何向您的产品团队和客户保证，如果无法进行试运行或“svn status -u”，应用程序不会崩溃成一大堆错误消息或“svn status -u”以确保部署将只修改那些需要修改的文件改变？通过检查状态，我什至可以知道是否有人强迫他们这样做并直接在服务器上进行“快速更改” - 你知道人们倾向于绕过对他们来说很快的事情的规则。

镜像直播服务器有错误？使用 .svn，您可以识别它同步到的确切版本（svn 信息），然后检查该 url 是否为真（sv status -u）。然后，您可以通过将相同的标签/版本签出到可以安全地排除故障的沙盒服务器来构建该设置的真实副本。

【讨论】：

【解决方案10】：

导出

就是这样。您没有任何充分的理由将额外的垃圾放入生产系统。

您将公开您的源代码
如果这是 Web 应用程序，那就更糟了，您的访问者可以下载您的源代码，这太酷了！非常开放:)

【讨论】：

为什么以及如何公开您的源代码？您是否通常也有其他不想展示给访客的东西？除了网站本身之外，您是否曾向访问者展示过任何内容？你允许目录列表吗？我从不。这就是 .htaccess 的用途。