我们使用一个 SVN 实例控制我们的代码库，并使用另一个实例来控制每个测试阶段和最终生产的环境和 Web 服务器的内容。掌握每个环境的历史记录已经为我们节省了很多次。让你的日志消息保持有意义肯定会有回报。
我从发送到我们的开发服务器的自动构建导出到系统测试文件的签出版本，然后提交对此的更改。更新网络场中的服务器只是更新所有机器上的 HEAD 版本。使用系统测试的导出来更新暂存，然后最终从暂存导出更新生产。其中某些部分是有脚本的，但手动监督很方便。也许最难的一点是确保配置文件对于每个环境都是正确的，但如果您不更改它，则不会部署它。
We control our code base with one instance of SVN and use another to control the environments and the contents of the web servers for each testing stage and eventually production. Having the history of what has been on each environment has saved us a number of times. Keeping your log messages meaningful will definitely pay off.
I export from the automatic build sent to our Dev server onto a checked out version of the System Test files and then commit the changes to that. Updating the servers in the web farm is just a case of updating to the HEAD revision on all the boxes. Staging is updated using an export from System Test and then Production is finally updated from a Staging export. Some parts of this are scripted but having manual oversight is convenient. Probably the hardest bit is ensuring the config files are correct for each environment but if you aren't changing it you don't deploy it.
You will probably still want to get to grips with feature branches or release branches and the necessary strategies to recombine the source. You may need to bug-fix something in Production you never expected no matter how good your testing strategy.
Each server in our deployment environment has the TortoiseSVN client installed so that the sysadmins have a GUI for updating the checked out repository.
I have also made them some scripts that use the SVN command line utilities to update a few repositories on the servers with an automated job. This allows our content team to commit files to their local copies of the server resources folder and then this updates every hour. They only have access to a that specific set of folders which we control with the auth file on the SVN server.
We have two separate machines that actually have SVN server installed which are backed up daily. One is for repositories of source code and the other one for the eventual builds that are deployed in each environment. It does mean we have a complete duplicate repository for the deployment in each environment but storage isn't an issue.
发布评论
评论（1）
我们使用一个 SVN 实例控制我们的代码库，并使用另一个实例来控制每个测试阶段和最终生产的环境和 Web 服务器的内容。掌握每个环境的历史记录已经为我们节省了很多次。让你的日志消息保持有意义肯定会有回报。
我从发送到我们的开发服务器的自动构建导出到系统测试文件的签出版本，然后提交对此的更改。更新网络场中的服务器只是更新所有机器上的 HEAD 版本。使用系统测试的导出来更新暂存，然后最终从暂存导出更新生产。其中某些部分是有脚本的，但手动监督很方便。也许最难的一点是确保配置文件对于每个环境都是正确的，但如果您不更改它，则不会部署它。
您可能仍然希望掌握功能分支或发布分支以及必要的策略重新组合源。无论您的测试策略有多好，您可能都需要在生产中修复一些您从未预料到的错误。
需要注意的一件事是不要将客户端版本 1.6x 与 1.5x SVN 服务器一起使用，因为这会破坏我们的合并进程，直到我们升级为止； http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx
编辑：
我们部署环境中的每台服务器都安装了 TortoiseSVN 客户端，以便系统管理员可以使用 GUI 来更新签出的存储库。
我还为他们制作了一些脚本，这些脚本使用 SVN 命令行实用程序来通过自动化作业更新服务器上的一些存储库。这允许我们的内容团队将文件提交到服务器资源文件夹的本地副本，然后每小时更新一次。他们只能访问我们通过 SVN 服务器上的身份验证文件控制的一组特定文件夹。
我们有两台独立的机器，实际上安装了 SVN 服务器，并且每天进行备份。一个用于源代码存储库，另一个用于在每个环境中部署的最终构建。这确实意味着我们在每个环境中都有一个完整的重复存储库用于部署，但存储不是问题。
We control our code base with one instance of SVN and use another to control the environments and the contents of the web servers for each testing stage and eventually production. Having the history of what has been on each environment has saved us a number of times. Keeping your log messages meaningful will definitely pay off.
I export from the automatic build sent to our Dev server onto a checked out version of the System Test files and then commit the changes to that. Updating the servers in the web farm is just a case of updating to the HEAD revision on all the boxes. Staging is updated using an export from System Test and then Production is finally updated from a Staging export. Some parts of this are scripted but having manual oversight is convenient. Probably the hardest bit is ensuring the config files are correct for each environment but if you aren't changing it you don't deploy it.
You will probably still want to get to grips with feature branches or release branches and the necessary strategies to recombine the source. You may need to bug-fix something in Production you never expected no matter how good your testing strategy.
One thing to note is not using client version 1.6x with a 1.5x SVN server as this is playing havok with our merge processes until we upgrade see; http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx
EDIT:
Each server in our deployment environment has the TortoiseSVN client installed so that the sysadmins have a GUI for updating the checked out repository.
I have also made them some scripts that use the SVN command line utilities to update a few repositories on the servers with an automated job. This allows our content team to commit files to their local copies of the server resources folder and then this updates every hour. They only have access to a that specific set of folders which we control with the auth file on the SVN server.
We have two separate machines that actually have SVN server installed which are backed up daily. One is for repositories of source code and the other one for the eventual builds that are deployed in each environment. It does mean we have a complete duplicate repository for the deployment in each environment but storage isn't an issue.