Intereting Posts
Как добавить параметры фильтра в контроллеры в Laravel? разница между функцией и функцией как оптимизировать mysql-запрос, если у меня слишком много операторов OR в моем запросе? Переопределение методов экземпляра Doctrine_Record (sfDoctrineRecord) в Doctrine PHP Symfony Можно выбрать диапазон дат в течение 65 лет с помощью JOIN? Чувствительность к регистру Yii PHP: отправить электронную почту через cronjob и установить количество отправки электронной почты за минуту Как установить переменную среды в MAMP? Отправьте <input type = "file" /> с помощью jQuery $ .post Вторая суббота месяца Функция в PHP Хороший способ идентифицировать похожие изображения? Как добавить Pagination в пользовательскую страницу списка плагинов Вставка Mysql только если предел не был достигнут Это регулярное выражение отключает последнее слово в строке, хотя strlen находится в допустимом диапазоне Отправить вложение файлов из формы с помощью phpMailer и PHP

Как вы управляете процессом сборки ?

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

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

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

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

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

    Идея заключалась в следующем:

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

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

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