使用版本控制工作流程的Web开发

Question

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

所以，我知道版本控制的基础知识，它现在的工作方式现在是错误的大时间。我已经通过维基百科和一些svn页面，但我找不到一个完美的解决方案应该如何实际工作。

难道你们有些经验丰富的人会建议这应该如何工作吗？

事情我已经找到了：

• 我们应该在本地副本上工作，我们的机器
• 那么我们更改提交SVN。

事情，我想知道：

• 我们怎样才能SVN后，web开发更新承诺？
• 如何将补丁部署到生产服务器？ FTP文件？这是你做的吗？或其他一些聪明的解决方案？
• 其他任何我应该了解的web-dev工作流程。

Answer 1

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

你也可以看看像CruiseControl.net或Team City这样的持续集成解决方案。

我们的过程是单个开发人员在本地配置上工作。我们承诺Subversion，CruiseControl.net会在我们每次提交时检查并构建系统。

有一个更新安装程序的计划构建，每周运行一次，并更新QA用于验证修补程序的服务器上的安装。一旦修复程序得到验证，某人（手动）将应用于生产站点上的QA服务器的更新应用到该服务器上。

Answer 2

我已经成功地使用如下

• 而是颠覆，使用分布式版本控制系统，如水银或Git的
• 所有的开发模型有他们承诺在当地的本地存储库部署期间
• 还有一个额外的测试存储库，所有开发人员在完成之后将其更改推送到该存储库。这是由QA检查并测试
• 如果所有的测试库是很好，这是标记，然后推到生产库

Answer 3

我建议在看后提交挂钩，像nickd建议。你甚至可以拒绝一个提交，如果它没有建立（比如说你从一些'源'文件生成HTML文件，并且如果这个生成失败，你可以指望这个人在提交之前修复它）。

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

，既可以自动通过挂钩，也可以考虑在生产机器手动“SVN更新”，它给你的时候，如此反复考虑使用哪个版本和控制。

SVN book是很好的阅读。人们只能阅读相关章节，稍后再回来阅读更多内容。您是否使用了干线和标签 - 它们是用于svn使用和释放控制的面包和黄油。

Answer 4

这就是我已经做了几年了。

开发服务器 - 位于内部，包含LAMP堆栈，存储库和一个工作副本。它具有与生产服务器相同的软件版本。

生产服务器 - 具有工作副本repo的分段环境，还具有非svn版本的项目（即活动站点）的生产环境。

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

典型流程：

开发人员更新项目的工作副本。在本地副本上工作，当完成当前更改并且无缺陷时，他们将复制回存储库。

Post-commit挂钩更新Dev Server的工作副本。您可能想要手动执行此操作，特别是如果您的团队开始增长。

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

如果更改在暂存环境中运行，那么我们使用RSYNC将暂存环境的工作副本中的任何更改推送到生产环境。

很显然，这是一个非常普遍的解释，因为你需要将诸如单元测试之类的东西集成到流程中，但我希望这有助于。

Answer 5

我们这样做的方式非常简单，作为一个小团队，您可能会涉及。

• 开发在本地主机上完成，并提交到中继线的一个分支。
• 对于QA，该分支合并到主干，和开发环境（这是躯干的复印件）只是做一个svn up
• 如果一切QA好，我在现场环境做一个svn up（这是也是一个主干的副本），我完成了。

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