Я большую часть своего времени являюсь разработчиком-одиночкой, работаю над рядом крупных проектов, в основном на 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 для этого, никаких проблем. Размещенные решения интересны для меня только в том случае, если они обеспечивают все описанные аспекты или являются достаточно гибкими для взаимодействия с другими частями процесса.

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

Я прошел через 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 со всеми нужными вам целями, вам повезло. Просто выберите «Вызвать муравья» и напишите название цели. Группа параметров также поддерживает команды 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/.

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

Он поддерживает 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

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

Вы можете просто настроить CI Jenkins для 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 - для тестирования производительности

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

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

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

Я запускаю среду 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, который, я думаю, мог бы использоваться для дальнейшей интеграции развертывания в ваш процесс.

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