Автоматическое веб-развертывание на нескольких серверах с Mercurial

Question

Недавно я рассматривал некоторые рабочие процессы для Mercurial, так как мы начинаем использовать его для нашей веб-разработки. Нам нужен автоматизированный способ распространения изменений, которые передаются в тестируемые и действующие экземпляры на несколько конечных точек. Вот схема идеи:

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

По сути, идея состоит в том, что все, что нам, как разработчикам, нужно было бы сделать, - это после того, как разработка достигла стабильного уровня, выдать команду push (которая не обязательно должна быть просто hg push). на тестовый сервер, и оттуда он будет автоматически распространяться. Затем, как только тестирование будет завершено, мы переместим его из теста в живую (или, если бы это было проще, мы могли бы перейти из dev в живую), и это также распространялось бы на каждый из различных экземпляров.

Было бы неплохо, если бы мы могли довольно легко добавить новые тестовые и живые экземпляры (например, если бы IP-адреса хранились в базе данных, которую можно было прочитать с помощью сценария и т. Д.).

Как лучше всего это сделать? Я знаю о ртутных крючках. Может быть, внутрипроцессный скрипт, который будет работать? Я также изучил Ткань , это был бы хороший вариант?

Кроме того, какое вспомогательное программное обеспечение потребуется каждой конечной точке? Было бы проще всего, если бы хранилище Mercurial существовало на каждом сервере? Будет ли полезен доступ по SSH? Etc ...

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 |
          +-------+             +-------+

• У меня нет репо на каждом веб-сервере; Я использую ткань для развертывания только того, что необходимо.
• У меня есть один файл fabfile.py (в репозитории), который содержит всю логику развертывания
• Набор серверов (IP) для развертывания предоставляется в виде командной строки arg to fabric (это часть конфигурации задания Jenkins)
• Я использую общие рабочие пространства Jenkins, чтобы можно было отделить задачи извлечения и компиляции от фактического развертывания (чтобы при необходимости можно было повторно развернуть тот же код)
• Если вам удастся сойтись с одной работой Дженкинса, которая тянет-компилирует-развертывает, вы будете счастливее. Совместно используемые рабочие пространства - это хак, который я должен использовать для своих настроек, и у него есть недостатки.

Чтобы напрямую ответить на некоторые ваши вопросы:

• Разработчики, работающие над тестовой веткой, могут работать в свободное время и совместно выбирать, когда запускать задание Jenkins для обновления тестовой среды.
• Когда тест пройдёт успешно, объедините его со стабильным и запустите задание Jenkins, чтобы обновить живую среду
• Добавление нового веб-блока - это просто вопрос добавления другого IP-адреса в командную строку, используемую для вызова фабрики (т. Е. В конфигурации для задания Jenkins)
• Всем серверам потребуется доступ по SSH из коробки Jenkins