Настройка цикла развертывания / сборки / CI для проектов PHP

Я большую часть своего времени являюсь разработчиком-одиночкой, работая над несколькими крупными, в основном, основанными на PHP проектами. Я хочу профессионализировать и автоматизировать процесс обработки изменений в коде, а также создать процесс непрерывной интеграции, который делает возможным переход к работе в команде без внесения фундаментальных изменений.

Сейчас я занимаюсь тем, что у меня есть локальная тестовая среда для каждого проекта; Я использую SVN для каждого проекта; Изменения тестируются локально, а затем передаются в онлайн-версию, обычно через FTP. API документация генерируется вручную из исходного кода; Модульные тесты - это то, чем я занимаюсь медленно, и это еще не часть моей повседневной жизни.

"Цикл сборки", который я предполагаю, будет делать следующее:

  • Набор изменений проверяется в SVN после локального тестирования.

  • Я начинаю процесс сборки. Ревизия SVN HEAD извлекается, модифицируется при необходимости и готовится к загрузке.

  • Документация по API генерируется автоматически - если я еще не настроил ее подробно, используя шаблон по умолчанию, сканирую всю базу кода.

  • Новая ревизия развернута в удаленном местоположении через FTP (включая переименование некоторых каталогов, chmodding, импорт баз данных и тому подобное.) Это то, что мне уже очень нравится, phing очень, но я, конечно, открыт для альтернатив.

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

  • (опционально) текстовый файл "changelog" для конечного пользователя в предопределенном месте обновляется с помощью предопределенной части сообщения фиксации ("Теперь можно фильтровать одновременно и"foo", и"bar") время). Это сообщение не обязательно совпадает с сообщением фиксации SVN, которое, вероятно, содержит гораздо больше внутренней информации.

  • Такие вещи, как метрики кода, проверка стиля кода и так далее, не являются моей основной задачей сейчас, но в долгосрочной перспективе они, безусловно, будут. Решения, которые приносят это из коробки, очень любезны.

я ищу

  • Отзывы и опыт людей, которые находятся или находились в аналогичной ситуации и успешно внедрили решение для этого

  • Особенно, хорошие пошаговые руководства и пошаговые руководства о том, как это настроить

  • Решения, которые обеспечивают максимально возможную автоматизацию, например, путем создания скелетного API, контрольных примеров и т. Д. Для каждого нового проекта.

а также

  • Рекомендации по продукту. На данный момент я знаю phing/ ant для сборки и phpUnderControl или Hudson для создания отчетов. Я люблю их всех, насколько я вижу, но у меня, конечно, нет подробного опыта с ними.

Я завален работой, поэтому у меня есть сильная склонность к простым решениям. С другой стороны, если функция отсутствует, я заплачу, что она слишком ограничена.:) Приветствуются и решения типа "укажи и щелкни". Я также к коммерческим рекомендациям продукта, которые могут работать с проектами PHP.

Моя настройка

Я работаю в Windows локально (точнее 7), и большинство клиентских проектов выполняются в стеке LAMP, часто на разделяемом хостинге (= без удаленного SSH). Я ищу решения, которые я могу использовать в своей среде. Я готов настроить виртуальную машину Linux для этого, никаких проблем. Размещенные решения интересны для меня только в том случае, если они обеспечивают все описанные аспекты или достаточно гибки для взаимодействия с другими частями процесса.

Щедрость Я принимаю ответ, который, как мне кажется, даст мне больше всего пробега. Здесь есть много отличных отзывов, я хотел бы принять более одного ответа. Спасибо всем!

9 ответов

Решение

Я прошел через buildbot, CruiseControl.net, CruiseControl и Hudson. Несмотря на то, что мне действительно нравился CruiseControl*, это было слишком много хлопот с действительно сложными случаями зависимости. buildbot нелегко настроить, но у него хорошая аура (я просто люблю python, вот и все). Но Хадсон победил первых трех, потому что:

  1. Это просто настроить
  2. Это легко настроить
  3. Выглядит хорошо и получил хороший обзор функциональности
  4. Он получил обновления по принципу "укажи и щелкни" для себя и всех установленных плагинов. Это действительно хорошая особенность, которую я ценю все больше и больше

Предостережение: я когда-либо использовал linux только в качестве базы для вышеупомянутых серверов сборки (CC.net работал на моно), но все они - в соответствии с документацией - запускались кроссплатформенными.

Настройка сервера Hudson

Предпосылки:

  • Java (1.5 отлично подойдет)
  • Доступ на чтение к серверу Subversion (у меня есть отдельная учетная запись для пользователя Hudson)

Отсюда просто:

java -jar hudson.war

Это запустит небольшой экземпляр сервера прямо с вашей консоли, и вы сможете просмотреть установку на вашем http://localhost:8080, если у вас больше ничего не запущено на этом порту заранее (вы можете указать другой порт, передав --httpPort=ANOTHER_HTTP_PORT опцию вышеупомянутой команды) и все прошло хорошо в процессе "установки".

Если вы идете в каталог доступных плагинов (http://localhost:8080/pluginManager/available), вы найдете плагины для поддержки вышеупомянутых задач (поддержка subversion устанавливается по умолчанию).

Если это вызывает у вас аппетит, вам следует установить сервер приложений java, например tomcat или jetty. Инструкции по установке доступны для всех основных серверов приложений

Обновление: Kohsuke Kawaguchi создал установщик службы Windows для Hudson

Настройка проекта в Гудзоне

Ссылки в следующем пошаговом руководстве предполагают наличие запущенного экземпляра Hudson, расположенного по адресу http://localhost:8080

  1. Выберите новую работу (http://localhost:8080/view/All/newJob) из меню слева
  2. Дайте работе имя и отметьте Build a free-style software project в списке
  3. Нажав "ОК", вы попадете на страницу конфигурации задания. Все варианты имеют небольшой знак вопроса, кроме них. Нажатие на это приведет к появлению справочного текста относительно опции.
  4. В группе параметров "Управление исходным кодом" вы будете использовать Subversion. Hudson принимает как URL-доступ, так и локальный модуль
  5. В группе параметров "Построить триггеры" вы будете использовать "Опрос SCM". Здесь используется синтаксис cron, поэтому опрос хранилища Subversion каждые 5 минут будет */5 * * * *
  6. Процесс сборки проекта указан в группе параметров "Построить". Если у вас уже есть файл сборки ant со всеми нужными вам целями, вам повезло. Просто выберите "Invoke ant" и напишите название цели. Группа параметров также поддерживает команды maven и shell прямо из коробки, но есть также плагин для phing.
  7. Отметьте дополнительные действия по сборке в "Действиях после сборки", такие как уведомления по электронной почте или архивация артефактов сборки.

Для настройки процессов, для которых у hudson нет плагинов, вы можете либо вызывать их напрямую через скрипт оболочки из настроек сборки, либо написать собственный плагин

Ловушки:

  • Если вы производите артефакты сборки, не забывайте регулярно чистить Хадсон после себя.
  • Если у вас настроено более 20 проектов, не отображайте их статус сборки в качестве главной страницы по умолчанию на hudson.

Удачи!

Вы ищете термин "непрерывная интеграция".

Вот пример того, кто использует GIT + phpundercontrol: http://maff.ailoo.net/2009/09/continuous-integration-phpundercontrol-git/

CruiseControl (который является CI-сервером) может использовать Hosted SVN/GIT в качестве источника. Так что вы даже можете использовать его с GitHub, Beanstalk или чем-то еще.

Затем вы можете интегрировать это со следующим типом программного обеспечения:

  • PHPUnit
  • PHP-codesniffer
  • PhpDocumentor
  • PHP Gcov
  • PHPXref
  • Yasca
  • и т.п.

Вы также можете попробовать этот размещенный CI: http://www.php-ci.net/hosting/create-project

Имейте в виду, однако, что эти инструменты нуждаются в специальной поддержке, если вы интегрируете их самостоятельно.

Вы также думали об управлении проектами и исправлениями?

Вы можете использовать Redmine для управления проектами. Он имеет встроенную поддержку непрерывной интеграции, но только на стороне клиента (а не на сервере CI).

Попробуйте использовать размещенный SVN/GIT/etc. решение, потому что они будут покрывать ваши резервные копии и поддерживать работу своих серверов, поэтому вы можете сосредоточиться на разработке.

Руководство по настройке Hudson см. По адресу: http://toptopic.wordpress.com/2009/02/26/php-and-hudson/

Я использую сервер непрерывной интеграции Bamboo Atlassian для своего основного проекта PHP (наряду с другими их продуктами, такими как fisheye (просмотр репозитория), jira ( средство отслеживания проблем) и clover (покрытие кода)).

Он поддерживает SVN и теперь поддерживает Git, и у него отличный пользовательский интерфейс. Он доступен для Linux, Windows и Mac и может работать автономно на своем собственном сервере Tomcat, что отлично подходит для людей (таких как я), которые не любят тратить дни на настройку своих инструментов). Хотя это может показаться дорогим, но я, будучи одиноким разработчиком, приобрел лицензию на стартовый набор за 10$ (10$ по программному обеспечению). Это отлично подходит для небольших команд и стоит посмотреть.

PHPTesting PHPCI Это хороший сервер непрерывной интеграции, встроенный в php.

Кроме того, это бесплатный и открытый исходный код.:)

это имеет количество плагинов..

PHPCI включает в себя интеграционные плагины для:

  • Atoum
  • Behat
  • Костер
  • Codeception
  • Композитор
  • Эл. адрес
  • хрюкать
  • IRC
  • PHP
  • корпия
  • MySQL
  • PDepend
  • PostgreSQL
  • PHP Code Sniffer
  • PHP Copy / Paste Detector
  • PHP Spec
  • PHP-модуль
  • Команды оболочки
  • Tar / Zip

Я в основном системный администратор, но иногда я пишу и PHP. В качестве стороннего проекта я создал несколько скриптов, которые сделают простую и безболезненной настройку полнофункциональной среды PHP CI с использованием Jenkins. Он также запускает пример проекта для вас, чтобы вы могли видеть, как настроен каждый шаг сборки.

Если вы хотите попробовать это, все, что вам нужно, это окно Debian/Ubuntu и доступ к оболочке.

http://yauh.de/articles/379/setting-up-a-ci-environment-for-php-projects-using-jenkins-ci

Обновление Чтобы добавить контент к моему ответу:

Вы можете просто настроить Jenkins CI для PHP с помощью Ansible. Начиная с версии 1.4, он поддерживает роли, которые вы можете загрузить с их сайта сообщества galaxy.ansibleworks.com, и он сделает тяжелую работу за вас. Это называется jenkins-php.

Я бы предложил использовать Jenkins http://jenkins-ci.org/ бесплатно и с открытым исходным кодом.

Его довольно просто настроить, он работает на нескольких платформах и хорошо интегрируется с другими инструментами непрерывной интеграции, такими как SonarQube (+ SQUALE) для измерения технического долга и Thucydides для автоматизации тестирования.

Я настоятельно рекомендую использовать GIT или GIT Hub для контроля версий вместо SVN. С моей точки зрения, это просто лучшая система контроля версий, которая поможет вам масштабировать ваши усилия по разработке позже.

Поскольку вы работаете в основном с PHP-проектом, вы можете использовать и другие инструменты.

PHPUnit - для модульного тестирования

PHP CodeSniffer - Проверка на стандарты кодирования

PHP Depend - показывает ваши зависимости кода PHP

XDEBUG - для тестирования производительности

Все эти инструменты и запускаются с заданием Дженкинса и помогают с качеством и производительностью вашего кода.

Удачи и Наслаждайтесь!

Я не использую многие продукты или даже типы продуктов, которые вы используете, но я дам вам свой опыт.

Я запускаю среду TEST параллельно со своей средой PROD. У меня нет локального тестирования как такового. Если слишком сложно внедрить что-либо в реальную среду TEST, тогда я исправлю процесс сборки. Я не вижу смысла в локальном тестировании, поскольку среда отличается. ОБНОВЛЕНИЕ: Единственное, что я делаю локально, это запускаю "php -l", прежде чем загружать что-либо. Останавливает глупые ошибки.

Процесс сборки работает со всем, что находится в текущем рабочем пространстве, включая незафиксированный код. Это не у всех чашка чая, но я очень часто собираюсь на ТЕСТ. Все передается в PROD.

Часть моего процесса сборки (похожая на вашу) создает два файла META. Один содержит последние (как правило) 100 изменений, а также дает мне текущий номер списка изменений. Показывает, какие изменения установлены. Другой содержит CLIENTSPEC (в терминах Perforce), который показывает мне, какие именно ветви использовались в этой сборке. Вместе они дают мне воспроизводимые сборки.

Я строю не прямо для целевой среды, а для промежуточной области на сервере. Я использую SSH, так что это имеет смысл. Это дает мне несколько преимуществ. Самое главное, что он не умирает на полпути через большую загрузку. Это также дает мне место для хранения файлов META, и все файлы сборки автоматически архивируются (поэтому я могу вернуться к любой сборке). Сценарий также регистрирует обновление (поэтому есть запись в потоке журнала, и я вижу до и после) и запускает все демоны (я использую daemontools, поэтому "svc -t"). Все это лучше на целевой машине.

Еще одна проблема - изменения БД. Я храню основной сценарий схемы БД, который я обновляю каждый раз, когда меняется схема. Каждое из изменений также входит в сценарий changes.sql, который загружается вместе со сборкой в ​​промежуточную область. Сценарий запускается как часть сценария установки.

Я недавно начал такой же процесс, и я использую Beanstalk для хостинга SVN.

В платных аккаунтах есть две отличные функции (я думаю, что они начинаются с 15 долларов):

  • Развертывание позволяет пользователю создавать цели ftp для промежуточных и производственных серверов, которые могут быть развернуты одним нажатием кнопки (включая указание ревизии и ветви).
  • webhooks позволяют пользователю устанавливать URL, который вызывается при каждом коммите / развертывании, передавая такие вещи, как номер редакции, описание и пользователь. Это может быть использовано для обновления документов, запуска модульных тестов и обновления журналов изменений.

Я уверен, что есть другие хостинговые или самодостаточные svn-серверы с этими двумя функциями, но у меня есть опыт beanstalk, и он работает очень и очень хорошо

Есть также API, который, я думаю, мог бы использоваться для дальнейшей интеграции развертывания в ваш процесс.

Рассмотрим http://www.fazend.com/, бесплатную CI-платформу, которая автоматизирует процедуры настройки и установки. Вам не нужно настраивать контроль версий, отслеживание ошибок, CI-сервер, тестовую среду и т. Д. Все выполняется по требованию.

Другие вопросы по тегам