1

我们已经决定了一个版本控制系统——使用 Mercurial 客户端和 Bitbucket 作为存储库。但我突然想到我们有一个我没有考虑过的问题。

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

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

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

任何建议将不胜感激。

提前致谢。

4

2 回答 2

1

我认为，您必须认真重新考虑使用过的工作流程，因为 LAMP-per-dev 仅比就地编辑站点好一点

  • 我看不到 Bitbucket 在严肃的企业发展中的位置 - 内部资源至少更易于管理
  • 我看不出为什么不将 Staging Mercurial-server（伪中央）与 Staging 内部 LAMP 服务器（您现在拥有并使用）一起使用

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

不易管理，实施速度更快

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

优点：简单、快速实施

缺点：无法防止（由于分布式特性）被其他开发人员的代码覆盖测试代码

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

LAMP-server 也成为 Mercurial-server，它托管所有站点存储库的“中央”克隆，仅通过来自开发人员本地存储库的推送进行更新。此服务器上的每个 repo 都必须有两个钩子：

  • “推前”检查，是否允许现在推，或网站被以前的开发者“锁定”
  • “post-push”，它导出复制接收到的数据并执行钩子 1 的控制功能：根据条件（讨论主题）锁定/解锁推送到 repo

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

优点：可管理的单点测试

缺点：由于推送工作流和推送阻塞可能导致延迟。需要安装、配置、支持额外的服务器。changegroup 和 pretxnchangegroup 钩子的复杂性

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

于 2012-11-27T03:29:56.460 回答
0

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

  1. 如果您真的对使用单个服务器作为演示服务器感兴趣，那么人们当时不积极地开发它可能会更好。他们可以那样破坏东西！开发人员在开发时不必担心会破坏东西。开发通常意味着试验。
  2. 让每个开发人员运行他们自己的服务器将使他们能够灵活地进行工作，例如，断开连接。你有一个分散的版本控制系统（mercurial），但是你的开发过程是高度集中的。即使您不希望人们远程工作，也要意识到当您的单台服务器出现故障时，每个人都会出现故障。
  3. 任何时候开发人员提交并推送这些提交，您都可以直接自动部署到您的演示站点。这样，您的演示服务器上仍然有一个相当最新的源代码。

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

于 2012-11-27T01:38:15.093 回答