Как вы управляете процессом сборки [используя Phing]?

Question

Я пытаюсь использовать Phing для автоматизации:

• выполнения тестов
• под управлением DB миграции на каждом компьютере разработчика [используя dbdeply]
• развертывания в производство при необходимости

Я думаю, имеет смысл добавить папку сборки в мой проект и поместить все мои файлы конфигурации сборки и db deltas в эту папку. и передать все это в репозиторий SVN. поэтому каждый разработчик получит обновленные файлы сборки, когда выйдет из svn. и иметь возможность запускать сборку, чтобы обновить свою БД новыми изменениями.

на рабочем сервере: Я планировал добавить еще один файл сборки, чтобы получить последнюю версию с тегами в svn и выполнить CSS & JS-сжатие.

---

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

так, вы думаете, что все это имеет смысл или у вас есть другие лучшие предложения?

Answer 1

Что вы говорите имеет смысл: это довольно близко к тому, что я часто использую (иногда с муравьями, иногда с phing, а иногда и с некоторыми shell-скриптами).

В каталоге build, я бы что-то вроде этого:

build/ 
    testing/ 
    development/ 
    staging/ 
    production/ 
    common/ 

С одной build.xml файл в каждом подкаталоге - все, включая другой build.xml файл, расположенный в каталоге common, идея в том, чтобы поместите как можно больший «общий» код в «общий» файл build.xml, а также для отдельных файлов, относящихся к среде, которые содержат как можно меньше xml-кода.

Это можно сделать с помощью задачи import, которая существует в последней версии phing (не уверен, что она находится в стабильной версии - я использую SVN checkout phing, чтобы иметь это, для проекта I в настоящее время работает).

Одна вещь: вы говорите, что хотите развернуть ее на производство с производственного сервера; Я предпочел бы, вместо того, чтобы:

• на сервере "развития":
  • экспорта из SVN
  • компресс JS/CSS, и все, что
  • создать деготь.GZ архива
• загрузка, что архив на сервер производства
• на сервере «производства»:
  • ун-компресс, что закачанного Архивировать
  • Измените пару линка использовать новую версию источники (см ответа, который я дал here, для получения дополнительной информации)
  • обновления, что должно быть сделано в БД

Идея заключается в том, чтобы:

• сделать как несколько вещей, как это возможно на производственном сервере
  • только в случае, если что-то пойдет не так
  • и в случае, один день, ваш производственный сервер не имеет доступа к серверу SVN
• для создания физического архива, который может быть развернут на нескольких производственных серверах

О, и, как заметка на полях: вы должны написать какую-то документацию «как развернуть на производство», шаг за шагом!

Это будет очень полезно день, когда вы находитесь в отпуске, и кто-то для развертывания производства из-за срочной баг-фикса ;-)