版本控制建议

Question

我们决定使用版本控制系统 - 使用Mercurial客户端和Bitbucket作为存储库。但是我刚刚遇到了一个我没有考虑的问题。

我们有一个内部开发LAMP服务器（Ubuntu），所有开发人员都在其上存储的网站上工作，这意味着所有开发人员共享一个文件源，我们都在使用它。很少有两个不同的开发人员会在同一时间在同一个站点上工作，但偶尔会发生这种情况。这意味着如果两个开发人员同时处理同一个文件，他们可以轻松地覆盖彼此的工作。

所以我的问题是：这个问题的最佳解决方案是什么？请记住，我们喜欢单个内部服务器的便利性，以便我们可以在内部演示站点，并且还有一个用于备份文件和数据库的cron作业。

我猜每个开发人员都必须在他们各自的工作站上运行他们自己的LAMP（或WAMP）服务器，提交并推送到bitbucket存储库。当然，无论何时在不同的网站上工作，都要按照惯例进行拉动并解决任何差异。这当然会剥夺其他团队成员（非开发人员）能够浏览到192.168.0.100（LAMP服务器IP地址）并查看网站进度的便利，更不用说某些客户端也可以访问同一台服务器外部（我设置了一个前向端口并限制其IP地址）以查看其网站的进度。

非常感谢任何建议。

提前致谢。

Answer 1

我认为，您必须认真重新思考关于已使用的工作流程，因为LAMP-per-dev仅比略微更好地比现场编辑网站

• 在严肃的企业发展中我看不到Bitbucket的位置 - 内部资源至少更易于管理
• 我看不出原因不使用Staging Mercurial-server（伪中心）和Staging内部LAMP服务器（你现在使用它）

我可以想象至少有两种可能的选择（快速，肮脏，草稿的想法，而不是现成的解决方案），两者都是基于hook的

管理不善，实施更快

每个开发人员都有自己的本地repo钩子，后面（每个？）提交导出他的提示并将副本导出到相关的站点空间。工作流程：提交 - 在内部网站上测试结果

优点：简单，快速实施

缺点：无法阻止（由于分布式性质）来自其他开发人员的代码覆盖测试代码

可管理的部署，更难实施和管理

LAMP-server也成为Mercurial-server，它托管所有site-repos的“中心”克隆，仅通过开发人员本地仓库进行更新。该服务器上的每个repo都必须有两个钩子：

• “推前”检查，是允许现在推送，还是由前任开发人员“锁定”的网站
• “后推”，导出复制接收数据并执行挂钩1的控制功能：根据条件（讨论主题）锁定/解锁推送回购

工作流程：提交 - 推送 - 测试结果 - 使用特殊（移动）标记标记WC - 提交标记 - 将解锁变更集推送到仓库

优点：可管理的单点测试

缺点：推送工作流程和推送阻塞可能导致延迟。需要安装，配置，支持其他服务器。 changegroup和pretxnchangegroup hooks的复杂性

解决方案2的最终说明和提示：我认为（未经过测试），特殊标记（使用-f进行变更集的移动）可以用作解锁标志（书签不满足条件“手动移动”）。即 - 开发人员提交（并推送）未标记的变更集，标记（f.e）“通过”标记一些较旧的变更集。在Staging服务器上测试结果完成后，开发人员使用上述标记标记WC，提交标记并推送到中央存储库。 changegroup hook必须检测推送.hgtags和（以某种方式）允许将来的数据推送（必须始终允许控制推送）

Answer 2

是的，更好的解决方案可能是为每个开发人员设置本地服务器。您可能看起来不方便，因为您显然习惯于共享服务器，但请考虑：

1. 如果您真的对使用单个服务器作为演示服务器感兴趣，那么当时人们并没有积极地开发它，可能会更好。他们可以这样打破东西！开发人员不应该担心在他们开发时会破坏东西。发展往往意味着试验。
2. 让每个开发人员运行自己的服务器将使他们具有灵活性，例如，断开工作。您已经拥有了分散版本控制系统（mercurial），但您的开发过程是高度集中的。即使您不希望人们远程工作，也要意识到当您的单个服务器现在停机时，每个人都会停下来。
3. 只要开发人员提交并推送这些提交，您就可以直接自动部署到您的演示站点。这样，您的演示服务器上仍然有一个非常新的源代码。

TL; DR：保留演示服务器，但让开发人员在他们自己的服务器上工作。