Svn 基于版本控制工作流的Web开发

简介：
我在一个双人团队工作（我们将来可能会扩展）。
我们有一个web开发服务器和一个生产服务器。
目前，当我们开始开发时，我们在localhost上启动它们，然后将它们部署到web dev（我们可以通过挂载的驱动器访问web dev），并将此“共享”驱动器的更改提交给SVN。对web开发人员的最终测试，通过FTP向我们的生产服务器发送来自上层和下层的批准。
（我能听到林奇来了……）
是的，我知道从一个位置共享文件并从那里提交文件都是错误的，但当我了解SVN时，这并不是一个坏主意。现在我想改变它

所以，我知道版本控制的基本原理，现在它的工作方式是错误的。我浏览了维基百科和一些svn页面，但我找不到一个完美的解决方案，它实际上应该如何工作

你们中一些经验丰富的人能建议这应该如何实际工作吗

我发现的事情：

• 我们应该在机器上制作本地副本
• 然后我们将更改提交给SVN

我想知道的事情：

• 在SVN提交后，我们如何进行web开发人员更新
• 如何将修补程序部署到生产服务器？ftp文件？你就是这么做的吗？还是其他聪明的解决方案
• 关于web开发工作流程，我还需要了解其他信息
Subversion提供了一个允许您在提交时执行操作的功能
您还可以考虑像CruiseControl.net或Team City这样的持续集成解决方案
我们的过程是单个开发人员处理本地配置。我们承诺进行Subversion，CruiseControl.net会在每次有人提交时检查并构建系统

---

有一个更新安装程序的计划构建，每周运行一次，并在QA用于验证修复的服务器上更新安装。一旦修复得到验证，就会有人（手动）将应用于生产站点上QA服务器的更新应用到生产站点上。
我成功使用的模型如下所示
• 不要使用subversion，而是使用分布式版本控制系统，如Mercurial或Git
• 所有开发人员都有一个本地存储库，他们在部署期间在本地提交该存储库
• 还有一个附加的测试存储库，所有开发人员在完成更改后都将其推送到该存储库。这由QA检查并测试
• 如果测试的存储库一切正常，则会对其进行标记，然后将其推送到生产存储库

---

我建议查看提交后挂钩，就像nickd建议的那样。如果提交未能生成，您甚至可以拒绝提交（例如，您从一些“源”文件生成HTML文件，如果该生成失败，您可以期望该人员在提交之前修复该问题）
• 在SVN提交后，我们如何进行web开发人员更新
• 如何将修补程序部署到生产服务器

自动地，通过钩子，或者你可以在生产机器上考虑一个手动的“Svn更新”，它控制你什么时候使用什么修改等等。

---

这本书读起来很棒。您可以只阅读相关章节，稍后再回来获取更多信息。您是否在使用trunk和tags？它们是svn使用和发布控制的基础。
这就是我几年来一直在做的事情
Dev服务器-位于内部，包含LAMP堆栈、存储库和一个工作副本。这与生产服务器的软件版本相同
生产服务器-具有带有repo工作副本的暂存环境，还具有带有非svn版本的项目（即活动站点）的生产环境
开发人员-在本地计算机上拥有LAMP堆栈和存储库的工作副本
典型过程：
开发人员更新项目的工作副本。在本地副本上工作，当当前更改完成且无错误时，他们将副本签回存储库
提交后钩子更新开发服务器的工作副本。您可能希望手动执行此操作，尤其是当您的团队开始成长时
如果更改在Dev服务器上工作，则手动更新临时环境上的工作副本
如果更改在暂存环境中工作，那么我们使用RSYNC将任何更改从暂存环境的工作副本推送到生产环境

---

显然，这是一个非常一般性的解释，因为您希望将单元测试之类的东西集成到流程中，但我希望这会有所帮助。
我们这样做的方式非常简单，而且作为一个小型团队，您可能能够联系到一起
• 开发在本地主机上完成，并提交给主干的分支
• 对于QA，分支与主干合并，而开发环境（是主干的副本）只执行一个

  svn up

• 如果QA中的一切都很好，我会在实时环境中执行

  svn up

  （这也是trunk的一个副本），我就完成了

---

我还没有这样做，但是这个过程可以通过添加一个post-commit钩子来简化，以自动更新开发环境（正如其他人所建议的）。
感谢您的帮助。我们将看一看持续集成的内容。不幸的是，我们目前不可能切换到其他版本控制解决方案。