Question

我们最近一直在寻找Mercurial的一些工作流程，因为我们开始将它用于我们的Web开发。我们需要一种自动方式将推送到测试和实时实例的更改传播到多个端点。这是一个想法的图表：

         +-------+
         |Dev    |
         |       |
         +-------+
             |  Push
             +--------+
                      |
                      V
+-------+   Push  +-------+
|Live   |<--------|Test   |
|server |         |server |
+-------+         +-------+
    |    +-------+    |    +-------+
    +--->|Live 1 |    +--->|Test 1 |
    |    |       |    |    |       |
    |    +-------+    |    +-------+
    |                 |
    |    +-------+    |    +-------+
    +--->|Live 2 |    +--->|Test 2 |
    |    |       |    |    |       |
    |    +-------+    |    +-------+
    |                 |
    |    +-------+    |    +-------+
    +--->|Live 3 |    +--->|Test 3 |
         |       |         |       |
         +-------+         +-------+

基本上，我们的想法是，我们作为开发人员必须做的就是，一旦开发达到稳定水平，就发出推送命令（它不一定只是{{1} }）到测试服务器，从那里它会自动传播出去。然后，一旦完成测试，我们就会将它从测试推送到实时（或者，如果它更容易，我们可以从dev推送到实时），那么它也会传播到每个不同的实例。

如果我们能够相当容易地添加新的测试和实时实例（例如，如果IP存储在可以由脚本读取的数据库中等等，那将是很好的。）

实现这一目标的最佳方法是什么？我知道Mercurial钩子。也许钩子会运行的进程内脚本？我也调查了Fabric，这是一个不错的选择吗？

此外，每个端点需要什么样的支持软件？如果每个服务器上都存在Mercurial存储库，那会是最简单的吗？ SSH访问是否有益？等...

Answer 1

我使用Mercurial，Fabric和Jenkins完成了类似的操作：

   +-------+
   | Devs  |
   +-------+
       | hg push
       V
   +-------+
   |  hg   |  "central" (by convention) hg repo
   +-------+\
    |        \
    |         +--------------+
    | Jenkins job            | Jenkins job
    | pull stable            | pulls test
    | branch & compile       | branch & compile
    |       +-------+        |
    |  +----|Jenkins|-----+  |
    |  |    +-------+     |  |
    V  |                  |  V
   +-------+          +-------+
   | "live"|          | "test"|  shared workspaces ("live", "test")
   +-------+          +-------+
     | Jenkins job         | Jenkins job     <-- jobs triggered
     | calls fabric        | calls fabric        manually in
     |    +-------+        |    +-------+        Jenkins UI
     |--> | live1 |        |--> | test1 |
 ssh |    +-------+    ssh |    +-------+
     |    +-------+        |    +-------+
     |--> | live2 |        |--> | test2 |
     |    +-------+        |    +-------+
     |    ...              |    ...
     |    +-------+        |    +-------+
     +--> | liveN |        +--> | testN |
          +-------+             +-------+

我在每个网络服务器上都没有回购;我使用fabric来只部署必要的东西。
我有一个包含所有部署逻辑的fabfile.py（在repo中）
要部署到的服务器（IP）集作为命令行arg给出结构（它是Jenkins作业配置的一部分）
我使用Jenkins共享工作区，因此我可以将拉取和编译的任务与实际部署分开（因此我可以在必要时重新部署相同的代码）。
如果你可以通过单一的Jenkins工作来完成拉动 - 编译 - 部署，你会更快乐。共享工作区的东西是我必须用于我的设置的黑客，并且有缺点。

直接解决您的一些问题：

在测试分支上工作的开发人员可以随意使用，并共同决定何时运行Jenkins工作来更新测试环境
当测试满意时，将其合并到stable并运行Jenkins作业以更新实时环境
添加新的Web框只是在用于调用结构的命令行中添加另一个IP（即在Jenkins作业的配置中）
所有服务器都需要来自Jenkins框的ssh访问

使用Mercurial在多台服务器上自动部署Web

1 个答案: