В первой части этой статьи я представил случай непрерывной интеграции. Теперь мы установим и настроим Jenkins для мониторинга автоматического построения простого демонстрационного PHP-приложения. Мы начнем с демонстрационного проекта, затем рассмотрим установку Дженкинса, и, наконец, настроим его и посмотрим, как он работает.
Демонстрационный проект
Демонстрационный проект основан на классе User и его тестовом скрипте, который использовала Мишель Санвер в своей статье Начало работы с PHPUnit . Чтобы все было организовано, я создал каталог с именем workspace в своем домашнем каталоге и настроил его так:
workspace имеет два подкаталога: .git который автоматически создается и используется Git, и builds папку стабильной версии.
Файл разработки — это User.php в workspace тогда как стабильный файл имеет то же имя, но находится в workspace/builds . Цель состоит в том, чтобы иметь возможность вносить изменения в workspace/User.php , тестировать эти изменения и, если они проходят, скопировать этот файл в workspace/builds .
Следующие строки создают рабочее workspace/builds каталогов и workspace/builds и инициализирует Git-репозиторий:
jajeronymo @ desktop: ~ $ mkdir -p рабочая область / сборки jajeronymo @ desktop: ~ рабочее пространство $ cd jajeronymo @ desktop: ~ / workspace $ git init Инициализированный пустой репозиторий Git в /home/jajeronymo/workspace/.git/
Для удобства я воспроизведу классы Мишель, которые должны быть соответственно сохранены как workspace/User.php и workspace/UserTest.php здесь:
<?php class User { protected $name; public function getName() { return $this->name; } public function setName($name) { $this->name = $name; } public function talk() { return "Hello world!"; } }
<?php require_once "User.php"; class UserTest extends PHPUnit_Framework_TestCase { public function testTalk() { $user = new User(); $expected = "Hello world!"; $actual = $user->talk(); $this->assertEquals($expected, $actual); } }
Чтобы запустить тест PHPUnit:
jajeronymo @ desktop: ~ / workspace $ phpunit UnitTest UserTest.php PHPUnit 3.6.10 от Себастьяна Бергмана. , Время: 0 секунд, память: 3,25 Мб ОК (1 тест, 1 утверждение)
Как вы знаете, точка во второй строке вывода означает, что User.php прошел тест.
И эта строка добавляет User.php в репозиторий Git:
jajeronymo @ desktop: ~ / workspace $ git add User.php
Добавление файла просто говорит Git, что он существует. Чтобы записать его как последнюю версию, мы должны зафиксировать это:
jajeronymo @ desktop: ~ / workspace $ git commit -m "Первая версия". User.php
Поскольку первоначальная версия User.php прошла тестирование, в настоящее время она является стабильной, поэтому мы должны скопировать ее в папку builds . Это можно сделать вручную, используя либо оконный файловый менеджер, либо в командной строке, как это, но на самом деле было бы лучше, если бы это было сделано какими-то автоматическими средствами, особенно для больших проектов, где копирование файлов может быть утомительным и подверженным ошибкам. ,
Apache Ant ищет файл с именем build.xml в домашней папке проекта и выполняет ряд операций, описанных в формате XML, например, в этом примере, который копирует последний User.php в папку builds:
<project name="user"> <copy file="User.php" tofile="builds/User.php"/> </project>
Сохраните вышеупомянутое в workspace/build.xml и запустите:
jajeronymo @ desktop: ~ / workspace $ ant -v
Ant должен вернуть вывод, который заканчивается аналогично:
[копия] Копирование 1 файла в / home / prospero / workspace / builds [копия] Копирование /home/jajeronymo/workspace/User.php в /home/jajeronymo/workspace/builds/User.php
На этом этапе проверенная копия User.php находится в папке стабильной версии и готова к отправке на User.php сервер. Для дальнейшей автоматизации процесса мы можем добавить тест в скрипт Ant:
<project name="user"> <exec executable="phpunit" failonerror="true"> <arg line=" UnitTest UserTest.php" /> </exec> <copy file="User.php" tofile="builds/User.php"/> </project>
Сохраните вышеупомянутое снова и запустите Ant:
jajeronymo @ desktop: ~ / workspace $ ant -v
Теперь мы получили две простые задачи для нашей упрощенной непрерывной интеграции: фиксация версий в Git и запуск Ant для тестирования кода, который в случае одобрения будет скопирован в текущую папку стабильной сборки. Итак, зачем нам нужен Дженкинс в конце концов?
Необходимость автоматизации и мониторинга
Чтобы ответить на это, я буду использовать IDE или текстовый редактор, чтобы внести небольшое изменение в User.php , скажем, добавить несколько дополнительных восклицательных знаков в «Hello World!». Как только я закончу, я добавлю новую версию в репозиторий Git:
jajeronymo @ desktop: ~ / workspace $ git commit -m "Добавлено несколько ударов". User.php [master d2c96bb] Добавлено несколько ударов. 1 изменение файлов, 1 вставка (+), 1 удаление (-) jajeronymo @ desktop: ~ / workspace $ ant -v
Но подожди минутку! Разве я не должен был проверить изменения перед их внесением? Конечно, я был! Давайте сделаем это сейчас, прежде чем кто-то получит непроверенный коммит!
Поскольку тест ожидает, User.php выходная строка User.php будет точно «Hello World!», Он вернет ошибку:
[ВЫПЛНЫ] [exec] Был 1 сбой: [ВЫПЛНЫ] [exec] 1) UserTest :: testTalk [exec] Не удалось утверждать, что две строки равны. [exec] --- Ожидается [exec] +++ Актуально [exec] @@ @@ [exec] - Привет, мир! [exec] + «Привет, мир !!!» [ВЫПЛНЫ] [exec] /home/prospero/workspace/UserTest.php:15 [exec] / usr / bin / phpunit: 46 [ВЫПЛНЫ] [exec] НЕУДАЧИ! [exec] Тесты: 1, Утверждения: 1, Сбои: 1. СТРОИТЬ НЕУДАЧИ /home/prospero/workspace/build.xml:4: exec вернул: 1
User.php … Я бы лучше вернулся в User.php и удалил эти лишние челки! Как только это будет сделано, я снова запущу Ant, прежде чем совершить коммит. Но вот когда зазвонил телефон, мое внимание требует неотложного вопроса, и User.php ускользает из моего разума. Вот почему нам нужен Дженкинс! Люди отвлекаются; компьютеры не делают.
Основная задача Дженкинса — не столько автоматизировать задачи, сколько контролировать их. На самом деле, автоматизация сборок — это не намного больше, чем работа cron, с которой справится любая приличная ОС. Дженкинс, конечно, облегчает создание таких заданий, называемых «триггерами». Но у него есть несколько других функций, связанных с определением того, кто несет ответственность за изменения, которые вызывают сбой теста, оповещение руководителей проектов, показ отчетов о возможных проблемах и многое другое. Вот откуда его полезность.
Настройка Дженкинс
Jenkins доступен на их веб-сайте в виде файла архива веб-приложения Java (.war) или в виде предварительно скомпилированных пакетов для нескольких популярных операционных систем. Используя WAR, просто поместите его в подходящую папку, скажем ~/jenkins и запустите:
jajeronymo @ server: ~ / jenkins $ java -jar jenkins.war
Это запускает Winstone, очень легкий контейнер сервлетов (своего рода сервер для приложений Java, который работает с Java более или менее так же, как веб-сервер работает с HTML и PHP). Терминал перечисляет несколько действий до окончания:
ИНФОРМАЦИЯ: Jenkins полностью запущен и работает
У Дженкинса есть веб-интерфейс, который прослушивает порт 8080. Указав свой браузер на http://localhost:8080 вы должны увидеть такой экран:
Чтобы создать наш демонстрационный проект, нажмите «Новая работа». Форма появится. Введите имя для работы (я введу «Демо») и выберите «Создать проект программного обеспечения в свободном стиле».
Затем нажмите OK, и длинный список параметров появится ниже в той же форме.
Ищите триггеры сборки и периодически проверяйте сборку. Появится текстовое поле с названием «Расписание». Напишите в нем «* / 5 * * * *». Это говорит Jenkins запускать процедуру сборки каждые 5 минут (здесь используется тот же синтаксис, что и в cron).
Перейдите в «Build» и нажмите «Add build step». Появится список параметров. Выберите «Invoke Ant» и нажмите кнопку «Advanced», которая появится. Эта кнопка показывает четыре текстовых поля. Во втором «Build file» напишите абсолютный путь к файлу build.xml используемому Ant. В моем случае это /home/jajeronymo/workspace/build.xml .
Перейдите в конец списка опций и нажмите «Сохранить». Это оно! С этого момента Jenkins будет запускать скрипт Ant каждые 5 минут, который, в свою очередь, проверяет любые изменения в User.php и, если ошибок не обнаружено, копирует его в папку сборки.
Из списка вакансий, который теперь отображается на начальной странице Jenkin, выберите нашу тестовую работу. В левой части окна вы можете увидеть список сборки. (Если он все еще пуст, вы можете нажать «Build now» в меню над ним, чтобы вызвать первую сборку).
Если вы исправили проблему в User.php , она должна пройти тест. Как только сборка заканчивается, Дженкинс добавляет в список ссылку с номером и временем выполнения, а рядом со ссылкой вы видите шарик — синий для успеха и красный для неудачи.
Нажав на ссылку, вы увидите меню, в котором вы можете выбрать изменения и пользователя, который запросил сборку. Нажатие на шар печатает вывод консоли Ant. Со временем сборки накапливаются. Вы можете поиграть с User.php , целенаправленно ломая и исправляя, и посмотреть, как это отражается в списке сборок и на выходе консоли.
Пока он остается запущенным, Jenkins будет неустанно запускать тест, и если проблем не будет найдено, перезапишите файл в сборке с последней стабильной версией User.php .
Резюме
Как было сказано в первой части, цель этой статьи заключалась в том, чтобы создать понимание проблем оперативной КИ, которые Дженкинс может решить для команды разработчиков. Наш пример был упрощен, но с этой и другими упомянутыми статьями заинтересованный читатель имеет инструменты для создания гораздо более сложных и полезных скриптов Ant. Об этом, пожалуйста, посетите http://jenkins-php.org/, где можно найти исчерпывающий шаблон для нескольких задач, связанных с разработкой PHP.
Изображение через Чарльза Тейлора / Shutterstock