Посмотрим на CI методом белого ящика. Нужно понимать, что система непрерывной интеграции состоит из множества подсистем. Во-первых, нам нужно система контроля версий (Git, HG и т.д.) из которой будут забираться исходники. Также нам нужен билд-скрипт, который компилирует код и нужны скрипты для развертывания базы данных. Помимо этого нам нужен сервис по запуску сборки, запуску тестов. В зависимости от желания, необходимости и возможностей инструментария можно прикрутить множество рюшечек, например, статический анализ кода, анализ покрытия кода тестами и другие. Таким образом, базовый процесс интеграции выглядит следующим образом:
Триггер. Событие, при котором запускается сборка продукта. Таким событием может быть: изменения в коде (push), определенное время, нажатие на кнопку.
После срабатывания триггера стартует сборка проекта из исходников.
Развертывание базы данных.
Развертывание приложения.
Тесты. Авто-тесты не являются обязательными, но их выполнение крайне желательно. Это один из важных пунктов хороших практик CI. К тестам мы еще вернемся.
Статус, отчеты, уведомления по результатам сборки. После прогона тестов получаем результат сборки, детальные отчеты по каждому из этапов интеграции
Если на пальцах, то система CI – это некая программа, которая следит за
вашим Source Control, и при появлении там изменений автоматически
стягивает их, билдит, гоняет тесты (конечно, если их пишут) и возможно
делает кое-что ещё.
Предположим, что у нас есть 2 машины, на одной из них (Master)
установлен и запущен Jenkins. Задача добавить вторую машину в Master.
Доступ из мастера в слейв будет осуществляться по ssh, поэтому нам надо (
хотя это совсем необязательно) сделать так, чтобы вход по ssh из мастера в слейв был без пароля, т.е. добавить ssh-ключ мастера в разрешенные ключи слейва.
Если по какойто причине вы не хотите это делать, то при настройке Slave машины можно будет все параметры SSH указать.
Ессно это все будет делаться для пользователя, под которым работает
Jenkins, т.е. пользователя jenkins, который создан по умолчанию.
Генерим ключ для мастера, если он еще не сгенерен:
Далее надо скопировать этот ключ (
id_rsa.pub) на слейв в пользователя jenkins. Либо копипастом либо можно через
ssh-copy-id
либо как Вам удобно. Я копирую 2ым способом. Для этого нам надо задать
пароль для пользователя jenkins на слейве, поскольку он создается без
пароля и мы не сможем зайти на слейв ;)
Ключ скопирован. Теперь надо сказать мастеру, что у него есть слейв. Делается это просто. Заходим в
Manage Jenkins ->
Manage Nodes, кликаем на
New Node и выбираем
Dumb Slave
На следующей странице нужно заполнить следующие поля:
- # of executors: 2 (число одновременных билдов)
- Remote FS root: /var/lib/jenkins (в моем случае такой путь)
- Labels: python27 natty
- Usage: Leave this machine for tied jobs only
- Launch method: Launch slave agents on Unix machines via SSH.
- Также конечно же необходимо заполнить поле Host field, вписав туда адрес Slave-машины.
Если вы не настраивали на слейве доступ по ssh-ключу, то под этим полем есть кнопочка Advanced, там можно указать логин/пароль.
Нажимаем OK и у нас в списке появляется новосозданный Slave. На разных
системах оно себя по разному ведет. В мануале написано, что после этого
надо кликнуть на новосозданную машину и нажать
Launch. У меня оно просто без вопросов подключилось.
Ну добавляйте сколько угодно компов...
Взято
тут
тут