生产环境的SVN签出或导出?

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非常陌生,但是当您创建一个新标记时,也许可以触发一个钩子脚本。这样,当您准备好更新live站点时,您只需将最后一次更改提交到主干,创建新标记,然后脚本使用svn update更新live站点。

我一直在努力解决这个问题,我想我终于决定结帐了。是的,那里有多余的垃圾,但是。。。

• 结帐更快。时期更新的文件越少意味着停机/转换时间越短,并且导出会下拉并覆盖所有内容,而不仅仅是需要更新的文件。

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

IMHO您应该创建一个分支/标记,其中包含用于生产的dev env的(所需)子集。应该有人手动或使用脚本自动维护此功能。然后,您应该导出(而不是签出)。增量更新不是问题,除非您正在更改生产环境中的文件,并且不希望覆盖这些文件。

只有我的0.02美元

毫无疑问——出口。

我想说,任何环境都应该只是一种出口;您仅在开发时在本地使用签出。当然,我们也在使用构建脚本,因此更新部署与运行脚本一样简单。

在开发代码中,为正在完成的任何工作创建分支。仅在准备部署到开发环境时才提交到主干。

我会研究一些部署软件,比如Capistrano(它是一个ruby程序)

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

当部署时间到来时,我只运行“checkinstall”,它创建一个包(RPM、DEB或TGZ,取决于我的目标Linux发行版)。我使用Linux发行包管理器(rpm、dpkg、pkgtool)提供的常规工具安装它。当然,如果您还想跟踪依赖关系,可以使用yum、apt-get等。

如果您想发布新版本的web应用程序,它会让您变得非常容易。到多个目标服务器。卸载、恢复到旧版本等都很容易,因为您部署的每个版本都有一个现成的软件包。

不过,如果您使用一些需要编译的东西,这可能不适合您的“经常推送”策略。然而,对于脚本编写(比如我做的PHP),在我的机器上创建一个包(包含300多个PHP文件)大约需要20秒。在任何目标系统上安装的数量都差不多。

为了将“for release”代码与“in development”代码分开,我使用了分支。使用Git非常简单,因为分支既便宜又快速。

就我个人而言,我一直对这个问题的解决方案持怀疑态度, 我更喜欢在我的生产环境中没有“.svn”目录,这太脏了 但同时,大型web应用程序的导出非常繁琐(尤其是使用一些第三方“组件”,如Extjs、FCKeditor等)。

我想一下。。。。。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复制到以前的发布版本,然后将符号链接从public移到新的构建目录。它比我在这里看到的任何东西花费的离线时间都要少,而且它还能让你更快地返回,除非你 ck

这里有一些意见-

如果.svn目录完好无损并且没有损坏,那么它们就不是脏的,它们实际上是救命稻草。为了安全起见,您可以告诉apache禁止浏览它们。

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

许可及;所有权 如果您了解并知道文件的权限,则可以在每次部署后运行脚本,以将CHOWN和CHMOD设置为所需的值。

恐惧与知识

在实时服务器上映像是否存在错误?使用.svn,您可以确定它同步到的确切版本(svn info),然后检查该url是否为真(sv status-u)。然后,您可以通过将相同的标记/版本签出到沙盒服务器(您可以在其中安全地进行故障排除)来构建该设置的真实副本。

出口

• 如果这是一个web应用程序,那就更糟糕了,你的访问者可以下载你的源代码,这是多么酷啊!非常开放:)