Установка развертывания / создает / цикл CI для проектов PHP
Я - одинокий разработчик большую часть моего времени, работающий в ряде больших, главным образом основанных на PHP проектов. Я хочу профессионализировать и автоматизировать, как изменения в кодовой базе обрабатываются и создают Непрерывный Процесс интеграции, который делает переход для работы в команде, возможной, не имея необходимость вносить коренные изменения.
Что я делаю, прямо сейчас, у меня есть локальная тестовая среда для каждого проекта; я использую SVN для каждого проекта; изменения тестируются локально и затем передаются интерактивной версии, обычно через FTP. Документация API сгенерирована вручную от исходного кода; Модульные тесты - что-то, во что я вхожу медленно, и это еще не часть моего распорядка дня.
"Цикл сборки" я предполагаю, сделал бы следующее:
В changeset зарегистрировались SVN, будучи протестированным локально.
Я запускаю процесс сборки. Пересмотр ГОЛОВЫ SVN проверяется, изменил при необходимости и приготовил для загрузки.
Документация API сгенерирована автоматически - если я подробно еще не настроил ее, с помощью шаблона по умолчанию, сканируя целую кодовую базу.
Новый пересмотр развертывается на удаленном местоположении через FTP (Включая некоторое переименование каталога, chmodding, импортируя базы данных и подобные.) Это уже - что-то я как phing для очень, но я открыт для альтернатив, конечно.
Выполняются модульные тесты, находящиеся в предопределенном месте. Мне сообщают об их отказе или успехе с помощью электронной почты, RSS или (предпочтительно) вывода HTML, который я могу захватить и поместить в веб-страницу.
(дополнительно) текстовый файл "журнала изменений" конечного пользователя в предопределенном месте обновляется с предопределенной частью сообщения о фиксации ("Теперь возможно отфильтровать и для "нечто" и для "панели" одновременно). Это сообщение не обязательно идентично с сообщением о фиксации SVN, которое, вероятно, содержит намного больше внутренней информации.
Материал как метрики кода, стиль кода, проверяющий и так далее, не является моим основным вниманием прямо сейчас, но на длительном периоде, они, конечно, будут. Решения, которые приносят этот out-of-the-box, очень любезно рассматриваются.
Я ищу
Обратная связь и события от людей, которые являются или были в аналогичной ситуации, и успешно реализовали решение для этого
Особенно, хорошие пошаговые руководства и пошаговые демонстрации о том, как настроить это
Решения, которые обеспечивают как можно больше автоматизации, например, путем создания скелета API, тестовые сценарии и так далее для каждого нового проекта.
и также
- Рекомендации продукта. Что я знаю, до сих пор phing/ant для создания, и phpUnderControl или Гудзон для части создания отчетов. Мне нравятся они все насколько я вижу, но у меня нет, конечно, подробного опыта с ними.
Я затопляюсь работой, таким образом, у меня есть сильный наклон к простым решениям. С другой стороны, если функция будет отсутствовать, то я буду кричать об этом слишком ограничиваемый.:) Решения для "укажи и выбери" приветствуются, также. Я также к коммерческим рекомендациям продукта, которые могут работать с проектами PHP.
Моя установка
Я работаю над Windows локально (7, чтобы быть точным), и большинство клиентских проектов выполняется на стеке LAMP, часто на общем хостинге (= никакой удаленный SSH). Я ищу решения, которые я могу выполнить в своей собственной среде. Я готов настроить VM Linux для этого, без проблем. Размещенные решения интересны для меня, только если они обеспечивают все аспекты, описанные, или достаточно гибки для взаимодействия с другими частями процесса.
Щедрость я принимаю ответ, который я чувствую, даст мне большую часть пробега. Существует много превосходного входа здесь, мне жаль, что я не мог принять больше чем один ответ. Спасибо все!
5 ответов
Я прошел через buildbot , CruiseControl.net , CruiseControl и Hudson . Хотя мне действительно нравился CruiseControl *, это было слишком хлопотно с действительно сложными случаями зависимости. buildbot нелегко настроить, но у него приятная аура (мне просто нравится python, вот и все). Но hudson выиграл у первых трех, потому что:
- Его просто настроить
- Легко настроить
- Он хорошо выглядит и имеет приятную функциональность обзора
- Он получил обновления для самого себя. и все установленные плагины. Это действительно хорошая функция, которую я ценю все больше и больше
. Предостережение: я когда-либо использовал 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 . Инструкции по установке доступны для всех основных серверов приложений.
Обновление : Кохсуке Кавагути создал установщик службы Windows для hudson
Настройка проект в hudson
Ссылки в следующем пошаговом руководстве предполагают, что запущенный экземпляр hudson расположен по адресу http: // localhost: 8080
- Выберите новое задание (
http: // localhost: 8080 / view / All / newJob) в меню слева - Дайте задание имя и отметьте
Создать проект программного обеспечения в свободном стилев списке - Нажатие кнопки «ОК» приведет к перенесет вас на страницу конфигурации задания. Все варианты имеют небольшой вопросительный знак. Нажатие на нее вызовет текст справки относительно опции.
- В группе опций «Управление исходным кодом» вы должны использовать Subversion. Hudson принимает как URL-доступ, так и доступ к локальному модулю
- В группе опций «Триггеры сборки» вы должны использовать «Опрос SCM». Здесь используется синтаксис cron, поэтому опрос репозитория Subversion каждые 5 минут будет
* / 5 * * * * - Процесс сборки проекта указан в группе опций «Build».Если у вас уже есть файл сборки муравья со всеми необходимыми целями, вам повезло. Просто выберите «Вызвать муравья» и напишите имя цели. Группа опций поддерживает команды maven и shell из коробки, но есть также плагин , доступный для phing .
- Отметьте дополнительные действия сборки в «Действиях публикации», такие как уведомления по электронной почте или архивирование артефактов сборки.
Для настройки процессов, для которых у hudson нет подключаемых модулей, вы можете либо вызвать их напрямую через сценарий оболочки из настройки сборки, либо вы можете написать собственный подключаемый модуль.
Ловушки:
- Если вы пусть он производит артефакты сборки, не забывайте, что hudson убирает за собой через регулярные промежутки времени.
- Если у вас настроено более 20 проектов, рассмотрите , а не отображение статуса их сборки в качестве главной страницы по умолчанию на hudson
Удачи!
Вы ищете термин «непрерывная интеграция».
Вот пример того, кто использует GIT + phpundercontrol: http://maff.ailoo.net/2009/09/continuous-integration -phpundercontrol-git /
CruiseControl (который является сервером CI) может использовать размещенный SVN / GIT в качестве источника. Таким образом, вы даже можете использовать его с GitHub, Beanstalk или чем-то еще.
Затем вы можете интегрировать это со следующим программным обеспечением:
- PHPUnit
- php-codeniffer
- phpdocumentor
- PHP Gcov
- PHPXref
- Yasca
- и т. Д.).
Вы также можете попробовать этот размещенный CI: http://www.php-ci.net/hosting/create-project
Имейте в виду, что эти инструменты нуждаются в специальной поддержке, если вы интегрируете их самостоятельно. .
Вы тоже думали об управлении проектами и исправлениями?
Вы можете использовать Redmine для управления проектами. Он имеет встроенную поддержку непрерывной интеграции, но только на стороне клиента (а не как сервер CI).
Попробуйте использовать размещенный SVN / GIT / и т. Д. решение, потому что они будут покрывать ваши резервные копии и поддерживать работу своих серверов, так что вы можете сосредоточиться на разработке.
Учебное пособие по настройке Hudson см .: http://toptopic.wordpress.com/2009/02/26/php-and-hudson/
Я недавно начал такой же процесс и использую Beanstalk для хостинга svn.
В платных счетах есть две функции (начиная с $15:00, я думаю):
- развертывание позволяет пользователю создавать FTP-цели для промежуточных и производственных серверов, которые могут быть развернуты при нажатии кнопки (inc, указывающей редакцию и ветвь)
- webhooks позволяют пользователю устанавливать URL, который вызывается при каждой фиксации/развертывании, передавая по таким вещам, как номер редакции, описание и пользователь. Это может использоваться для обновления документов, выполнения единичных тестов и обновления журналов изменений.
Я уверен, что есть и другие хостинговые или автономные серверы svn с этими двумя функциями, но beanstalk - это тот, с которым у меня есть опыт, и он работает очень, очень хорошо
Есть также API, который, я полагаю, можно использовать для дальнейшей интеграции развертывания в ваш процесс.
Я использую сервер непрерывной интеграции Atlassian Bamboo для своего основного проекта PHP (вместе с другими их продуктами, такими как fisheye ] (просмотр репозитория), jira (средство отслеживания проблем) и clover (покрытие кода)).
Он поддерживает SVN, теперь поддерживает Git и имеет отличный пользовательский интерфейс. Он доступен для Linux, Windows и Mac и может работать автономно на собственном сервере Tomcat, что отлично подходит для людей (таких как я), которые не любят тратить дни на настройку своих инструментов). Хотя это может показаться дорогим, я, будучи разработчиком-одиночкой, купил лицензию на стартовый комплект за 10 долларов (10 долларов за программное обеспечение). Это отлично подходит для небольших команд, и на это стоит обратить внимание.
Я не использую многие из продуктов или даже типов продуктов, которые используете вы, но я расскажу вам о своем опыте.
Я запускаю среду TEST параллельно с моей средой PROD. У меня нет локального тестирования как такового. Если что-то слишком сложно запустить в реальной тестовой среде, тогда я исправляю свой процесс сборки. Я не вижу смысла в локальном тестировании, так как окружения разные. UPDATE: Единственное, что я делаю локально, это запускаю "php -l" перед загрузкой чего-либо. Это останавливает глупые ошибки.
Процесс сборки работает со всем, что находится в текущем рабочем пространстве, что включает в себя нефиксированный код. Это не всем по вкусу, но я очень часто перехожу на TEST. Все фиксируется перед отправкой в PROD.
Часть моего процесса сборки (похожего на ваш) создает два файла META. Один содержит последние (обычно) 100 изменений, а также дает мне номер текущего списка изменений. Это показывает мне, какие изменения установлены. Другой содержит CLIENTSPEC (в терминах Perforce), который показывает мне, какие именно ветви были использованы в этой сборке. Вместе это дает мне воспроизводимые сборки.
Я собираю не прямо в целевую среду, а в область хранения на сервере. Я использую SSH, поэтому это имеет смысл. Это дает мне несколько преимуществ. Самое главное - это позволяет не умереть на полпути при большой загрузке. Это также дает мне место для хранения META-файлов, а все файлы сборки автоматически архивируются (так что я могу вернуться к любой сборке). Сценарий также регистрирует обновление (так что есть запись в потоке журнала, и я могу видеть до и после) и отбрасывает всех демонов (я использую daemontools, так что "svc -t"). Все это лучше делать на целевой машине.
Еще одна проблема - изменения в БД. Я храню мастер-скрипт схемы БД, который обновляю каждый раз, когда схема меняется. Все изменения также попадают в скрипт changes.sql, который загружается вместе со сборкой в область хранения. Этот сценарий запускается как часть сценария установки.