带有版本控制工作流程的 Web 开发

Question

简介：
我在一个 2 人团队中工作（我们将来可能会扩大）。
我们有一个网络开发服务器和一个生产服务器。
目前，当我们开始开发时，我们在 localhost 上启动它们，然后我们将它们部署到 web-dev（我们可以通过已安装的驱动器访问它）并将更改从这个“共享”驱动器提交到 SVN。在 web-dev 上进行最终测试，从顶部获得批准，然后通过 FTP 到我们的生产服务器。
（我能听到林奇来了……）
是的，我知道从一个位置共享文件并从那里提交文件都是错误的，但是当我了解 SVN 时，这并不是一个坏主意。现在我想改变它。

所以，我知道版本控制的基础知识，而且它现在的工作方式大错特错。我浏览了 wikipedia 和一些 svn 页面，但我找不到一个完美的解决方案，它应该如何实际工作。

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

我发现的东西：

• 我们应该在我们的机器上处理本地副本
• 然后我们将更改提交到 SVN。

我想知道的事情：

• 我们如何在 SVN 提交后更新 web-dev？
• 如何将补丁部署到生产服务器？ .ftp 文件？这是你做的吗？还是其他一些巧妙的解决方案？
• 关于网络开发工作流程我应该知道的任何其他信息。

Answer 1

Subversion 有 post commit hooks，它允许您在提交时执行操作。

您还可以查看 CruiseControl.net 或 Team City 等持续集成解决方案。

我们的流程是由个别开发人员处理本地配置。我们提交 Subversion，CruiseControl.net 每次提交时都会检查并构建系统。

更新安装程序有一个计划构建，每周运行一次，并在 QA 用来验证修复的服务器上更新安装。验证修复后，有人（手动）应用已应用于生产站点上 QA 服务器的更新。

Answer 2

我建议查看 post commit hooks，就像 nickd 建议的那样。如果提交失败，您甚至可以拒绝提交（例如，您从一些“源”文件生成 HTML 文件，如果该构建失败，您可以期望该人在提交之前修复该问题）。

• 我们如何在 SVN 提交后进行 web-dev 更新？
• 如何将补丁部署到生产服务器？

通过钩子自动进行，或者您可以考虑在生产机器上手动“svn 更新”，这样您就可以控制何时、哪个版本等使用。

SVN book 非常适合阅读。人们只能阅读相关部分，稍后再回来阅读更多内容。你在使用主干和标签吗？它们是 svn 使用和发布控制的基础。

Answer 3

这就是我几年来一直这样做的方式。

Dev Server - 位于内部，包含 LAMP 堆栈、存储库和工作副本。这与生产服务器具有相同版本的软件。

生产服务器 - 具有带有 repo 工作副本的暂存环境，还具有带有非 svn 版本项目（即实时站点）的生产环境。

开发人员 - 在其本地计算机上拥有 LAMP 堆栈和存储库的工作副本。

典型流程：

开发人员更新项目的工作副本。在本地副本上工作，当当前更改完成并且没有错误时，他们会将副本检查回存储库。

提交后挂钩更新 Dev Server 的工作副本。您可能希望手动执行此操作，尤其是当您的团队开始增长时。

如果更改在 Dev Server 上有效，则手动更新暂存环境中的工作副本。

如果更改在临时环境中起作用，那么我们使用 RSYNC 将任何更改从临时环境的工作副本推送到生产环境。

显然，这是一个非常笼统的解释，因为您希望将单元测试等内容集成到流程中，但我希望这会有所帮助。

Answer 4

我使用成功的一个模型如下

• 不要使用 subversion，而是使用分布式版本控制系统，例如 Mercurial 或 Git
• 所有开发人员都有一个本地存储库，他们在部署期间将其提交到本地
• 还有一个额外的测试存储库，所有开发人员在完成更改后将其推送到该存储库。这已由 QA 检查并测试
• 如果测试存储库一切正常，则会对其进行标记，然后推送到生产存储库

Answer 5

我们做这件事的方式很简单，作为一个小团队，你也许可以联系起来。

• 在本地主机上完成开发并提交到主干的一个分支。
• 对于 QA，分支与主干合并，而开发环境（主干的副本）只执行 svn up
• 如果在 QA 中一切正常，我会在实时环境中执行 svn up（这也是主干的副本），然后我就完成了。

我还没有这样做，但是这个过程可以通过添加一个 post-commit 钩子来自动更新开发环境来简化（正如其他人所建议的那样）。