Я пытаюсь использовать Phing для автоматизации:
Я думаю, что имеет смысл добавить папку сборки в мой проект и поместить все мои файлы конфигурации сборки и db deltas в эту папку. и передать все это в репозиторий SVN. поэтому каждый разработчик получит обновленные файлы сборки, когда выйдет из svn. и иметь возможность запускать сборку, чтобы обновить свою БД новыми изменениями.
на рабочем сервере: я планировал добавить еще один файл сборки, чтобы получить последнюю версию Tagged в svn и выполнить сжатие CSS и JS.
Я планировал также реализовать интеграцию с использованием PHPUnderControl, поэтому я могу отслеживать результат каждой сборки и получать уведомление о сбое сборки.
так, как вы думаете, это все имеет смысл, или у вас есть другие лучшие предложения?
То, что вы говорите, имеет смысл: оно довольно близко к тому, что я часто использую (иногда с муравьем, иногда с phing, а иногда и с некоторыми shell-скриптами) .
В каталоге build меня будет что-то вроде этого:
build/ testing/ development/ staging/ production/ common/
С одним файлом build.xml в каждом подкаталоге – все, включая другой файл build.xml , расположенный в common каталоге, идея заключается в том, чтобы как можно больше «общего» кода в «общем» файле build.xml , и иметь файлы, зависящие от среды, которые содержат как можно меньше xml-кода.
Это можно сделать с задачей import которая существует в последней версии phing (не уверен, что она находится в стабильной версии – я использую SVN checkout phing, чтобы иметь это, для проекта, над которым я сейчас работаю ) .
Одна вещь, однако: вы говорите, что хотите развернуть производство с производственного сервера; Вместо этого я предпочел бы:
Идея заключалась в следующем:
О, и, в качестве побочного элемента: вам нужно поэтапно написать какую-то документацию «как развернуть на производство»!
Это будет действительно полезно в тот день, когда вы находитесь в отпуске, а кто-то еще должен разворачиваться на производство из-за срочного исправления ошибок 😉