Непрерывная интеграция — это метод контроля качества программного обеспечения, который проверяет целостность кода всякий раз, когда вносятся небольшие изменения, а не ожидает завершения всего кода перед его тестированием и отладкой.
CI требует контроля версий, автоматического модульного тестирования и постоянной сборки пакетов. В принципе, автоматизированная часть цикла может быть выполнена с помощью заданий cron, которые запускают такие программы, как xunit (тестер) и make (сборщик). Однако в последние несколько лет появились более удобные и находчивые инструменты, такие как Jenkins, который объединяет задачи автоматизации и контроля в единую систему.
То, что делает Дженкинс, не трудно понять, если вы знаете, почему это происходит. В этой серии из двух частей я представлю общий обзор проблем программирования, которые может решить CI, покажу, как этого можно достичь с помощью специализированного программного обеспечения, и объясню, как можно минимально использовать Jenkins для периодического запуска тестирования и создание приложений PHP (веб), ведение учета того, где интеграция прошла успешно или не удалось, и поддержание папки «output» в актуальном состоянии с последними файлами, которые требуются приложению, готовыми для загрузки на сервер.
Кстати, мне не нужно заботиться о том, чтобы сделать читателя экспертом в Jenkins, потому что им так легко пользоваться, что, как только его основная цель понята, сложные ресурсы следуют естественным образом.
Большая картина
Реализуя программу досрочного выхода на пенсию, The One Big Worldwide Corporation, Inc. предложила своим сотрудникам предложения о том, как использовать свое новое качественное время. Одним из них было программирование для Интернета, будь то для развлечения, общественных работ или для собственного малого бизнеса. Несколько человек проявили интерес, и отдел обучения купил им серию очень хороших книг по всем аспектам веб-дизайна и разработки, опубликованных австралийской компанией, которая также поддерживает некоторые из лучших в мире веб-сайтов по этой теме.
Среди тех, кто начал заниматься PHP-программированием для Интернета, были три бывших внешнеторговых оператора, которые, работая в прошлом часто, решили создать онлайновую сеть бывших сотрудников: Берта, которая живет в Буэнос-Айресе, Аргентина, Алисия , который проживает в Иокогаме, Япония, и Мива из Бонна, Германия. Кроме того, Гвидо, бывший специалист по персоналу в Турине, Италия, решил создать свой собственный бизнес веб-разработки и хостинга.
Чтобы начать работу с сетевым приложением, Берта предложила написать сценарий поиска в базе данных, в то время как Алисия вызвалась разработать HTML-интерфейс, а Miwa решила атаковать код для добавления / редактирования / удаления записей. Они договорились встречаться онлайн раз в неделю, чтобы проверить свои результаты.
Первые пару недель все шло гладко, но вскоре после того, как возникли проблемы, Берта решила, что именование переменных в $camelCaseNaming не очень хорошо, и изменила все на $underscore_separated_names , Алисия переименовала некоторые поля формы интерфейса, а Мива изменил способ работы базы данных даты. Когда они собрались вместе и протестировали приложение, ошибки начали появляться как кукуруза на One and Only Famous Popcorn Machine от One Big Worldwide Corporation.
Тем временем в Италии Гвидо с трудом следил за файлами разработки, разбросанными по всему его жесткому диску, некоторые из которых были более новыми и более старыми, чем версии на серверах его клиентов, поэтому устранение проблемы на одном веб-сайте неизменно приводило к поломке другого.
Дамы и Гвидо были в том, что иногда называют «адом интеграции», из-за которого многие молятся святому Исидору, которого некоторые считают покровителем Интернета, или непрерывной интеграции.
Непрерывная интеграция (CI) — это метод разработки, при котором любое изменение файла, независимо от его размера, должно быть документировано, протестировано и отправлено в центральное хранилище с управлением версиями, а пакеты собираются в плановом порядке, исключая все, что есть. не требуется для запуска приложения.
Непрерывная интеграция помогает убедиться, что все работают над последней версией кода, что никакие необъявленные изменения в файле A не ставят под угрозу разработку файла B, что в любое время требуется не более нескольких исправлений, чтобы вернуть B к работе с A и что пакеты автономны, аккуратно организованы и не содержат ненужных промежуточных файлов.
Контроль версий
Прочитав замечательную статью Шона Хадгстона « Введение в Git» , которую я рекомендую тем, кому еще нужно познакомиться с этим потрясающим инструментом (я имею в виду, сейчас!), Дамы и Гвидо решили использовать Git-менеджер Линуса Торвальдса, чтобы попытаться получить Весь их код организован в одном месте.
Работая в одиночку, Гвидо создал репозиторий на своем настольном компьютере, создав зонтичный каталог ( /www ) с подпапкой для каждого проекта, например /www/formaggeria_centrale и /www/assicurazione_chiapetta .
Леди нуждались в удаленном репозитории, к которому каждый мог бы получить доступ, и они выбрали учетную запись GitHub, создав проект, который они назвали «прежний_мплой», и согласились, что каждый может git add файл, как только его создание или редактирование будет завершено.
Модульное тестирование
Фундаментальным шагом в тестировании программного обеспечения является постоянная проверка того, работает ли новый код так, как это должно быть, прежде чем помещать его в репозиторий Git. Это называется модульным тестированием , и оно может быть выполнено в PHP с помощью фреймворка PHPUnit Себастьяна Бергмана.
По-видимому, именно Мива прочитала « Начало работы с PHPUnit» моей коллеги Мишель Санвер и начала писать тесты для ее части приложения. Это оказалось успешным и вскоре имитировали другие.
Строительство
Как только было показано, что код функционирует и зафиксирован в репозитории, возникла проблема создания пакетов для простого развертывания на рабочем сервере путем отделения файлов, необходимых для запуска приложения, от файлов, используемых для поддержки разработки.
Взяв на себя ответственность за это для женской команды, Алисия записала список типов файлов, которые следует исключить (например, файлы .xcf для проектов изображений Gimp) и список тех (например, .php и .png), которые будут включены в сжатый файл. Это было легко, но подвержено ошибкам.
Apache Ant запускает пакет задач, в противном случае выполняется одно за другим. Он читает созданный пользователем скрипт с такими действиями, как «скопировать это туда» и «удалить это отсюда». Гвидо уже использовал его, и он направил Алисию в учебник по муравьям на веб-сайте Apache. Очень скоро она создала свой собственный скрипт и начала автоматизировать не только сборки, но и тестирование.
надзор
В теории все работает нормально, но, увы, бедный Йорик !, на практике вскоре возникли другие проблемы. Мива пропустил некоторые модульные тесты, заставляющие группу тратить время на плохой код, который в конечном итоге пришлось исправить. В свою очередь, чтобы быть в безопасности, Гвидо проводил много времени, повторяя тесты, в которых он не был уверен, сделал он это или нет.
И группа, и одинокий разработчик не раз забывали создавать пакет, в результате чего старые, поврежденные версии некоторых файлов попадали на рабочие серверы. Вот тут и появился надзорный инструмент.
Дженкинс
Созданный в Sun Microsystems Kohsuke Kawaguchi, которому, похоже, было достаточно ручных интеграций, Дженкинс начал свою жизнь как Hudson, среда надзора за автоматизацией CI, написанная на Java. С поглощением Sun Oracle, сообщество сменило название с Hudson на Jenkins, что фактически стало разветвлением.
Дженкинс, и в этом отношении Хадсон, следит за выполнением различных задач, требуемых CI, помогая улучшить стиль кодирования, ища дублирующий код и операторы, которые кажутся излишне сложными. Jenkins был создан для разработки Java, но теперь с помощью плагинов он может предоставлять услуги многим языкам программирования.
Во второй части этой статьи мы установим и настроим Jenkins для управления периодическим тестированием и сборкой простого проекта PHP, который также требует контроля версий, модульного тестирования и программ автоматизации сборки. Мы закончим эту первую часть установкой.
Git, PHPUnit И Apache Ant
Прежде чем мы сможем использовать Jenkins с нашим демонстрационным проектом PHP, нам нужно установить Git (система контроля версий), PHPUnit (тестер модулей для PHP) и Apache Ant (сборщик пакетов).
Git доступен в репозиториях кода Linux, а их веб-сайт предлагает установщики для Mac и Windows. После установки проверьте его, набрав:
jajeronymo @ server: ~ $ git --version
PHPUnit должен быть установлен с помощью PEAR, расширения PHP и хранилища приложений, иначе. В Linux убедитесь, что ваша PEAR является последней стабильной версией и запустите:
jajeronymo @ server: ~ $ sudo pear config-set auto_discover 1 jajeronymo @ server: ~ $ sudo pear install pear.phpunit.de/PHPUnit
После завершения обычного процесса установки проверьте, работает ли он:
jajeronymo @ server: ~ $ phpunit --version
Apache Ant также является программным обеспечением Java и не требует установки. Пакеты двоичных файлов доступны на их странице загрузки . Основные дистрибутивы Linux могут иметь пакеты в своих репозиториях. После того, как вы установили его, снова запустите тест из интерфейса командной строки:
jajeronymo @ server: ~ $ ant -version
Обратите внимание, что Ant требует только одну черту перед опцией «версия»!
На данный момент у нас есть все, что нужно, кроме самого Дженкинса, о котором пойдет речь во второй части этой статьи. До тех пор, будьте осторожны!
Изображение через Чарльза Тейлора / Shutterstock