在我正在开发的项目中,我们在开发团队之间进行了持续的讨论 - 生产环境是作为SVN存储库的结账部署还是作为导出进行部署?
开发环境显然是一个结账,因为它不断更新.对于制作,我亲自检查主干,因为它使未来的更新更容易(只需运行svn update).然而,一些开发人员反对它,因为svn使用svn进程的组/所有者和权限创建文件(这是在Linux操作系统上,所以那些事情很重要),并且生产中的.svn目录似乎也是如此他们有点脏.
此外,如果是结帐 - 如何在不包含开发代码的情况下将单个功能推送到生产中?你是否为每个功能使用标签或分支?任何替代品?
编辑:我可能不太清楚 - 其中一个要求是能够始终能够将修复程序推送到生产环境.我们希望避免完整构建(比简单更新需要更长的时间),仅用于推送关键修复.
Subversion FAQ似乎主张将部署作为结帐,并使用提交后的钩子脚本进行自动更新.它们通过在httpd.conf中添加以下内容来阻止Apache导出.svn文件夹(可能是个好主意):
# Disallow browsing of Subversion working copy administrative dirs.Order deny,allow Deny from all
我对自己非常陌生,但也许你可以在创建一个新标签时触发一个钩子脚本.这样,当您准备好更新实时网站时,您只需将最后一次更改提交到主干,创建新标记,脚本将使用svn update更新您的实时网站.
我一直在努力解决这个问题,我想我终于决定结帐了.是的,那里有额外的垃圾,但......
导出不考虑已删除的文件(除非您的解决方案是删除目录和THEN导出中的所有内容,我认为这更糟糕).Checkout将删除已删除的文件.
结帐速度更快.期.更新的文件越少意味着更少的下行/转换时间,导出下拉并覆盖一切,而不仅仅是需要更新的文件.
不是说这对每个人都有效,但这两件事影响了我的决定.祝你好运.
恕我直言,您应该创建一个分支/标签,其中您拥有用于生产的dev env的(所需)子集.有人应该手动维护或使用脚本自动维护.然后,您应该导出(而不是结帐).增量更新不是问题,除非您要更改生产环境中的文件,并且不希望覆盖这些文件.
只需我0.02美元
没问题 - 出口.
您不会进行更新,因此没有理由进行结帐.你只是要部署垃圾.
我想说任何环境应该只是出口; 您只在开发时使用本地结帐.当然我们也在使用构建脚本,因此更新部署就像运行脚本一样简单.
就开发代码而言,为正在进行的任何工作创建分支.只有在准备好部署到开发环境时才提交到主干.