PHP Удалить Phing после PROD Deploy

Question

В настоящее время мы используем phing при развертывании от jenkins до наших различных сред. Мы используем его для очистки. Мы хотели бы удалить phing из папки source / vendor после завершения сборки.

Может ли phing удалить себя как последний шаг сборки?

Или я должен просто сделать команду rm -rf phing /?

Answer 1

Представьте, что вашему проекту нужно много зависимостей, например ramsey/uuid, phing/phing и pds/skeleton. Используйте composer require для добавления зависимостей, но используйте опцию --dev при добавлении зависимостей разработки:

composer require ramsey/uuid
composer require --dev phing/phing
composer require --dev pds/skeleton

Содержание вашего composer.json должно быть следующим:

{
  "require": {
    "ramsey/uuid": "^3.8"
  },
  "require-dev": {
    "pds/skeleton": "^1.0",
    "phing/phing": "^2.16"
  }
}

Чтобы установить все ваши зависимости, используйте следующую команду:

composer install 

Теперь, если вы хотите удалить зависимости разработки, наберите:

composer install --no-dev

Последняя команда только установит ваши производственные зависимости и сразу удалит ваши зависимости для разработки из каталога vendor.

Answer 2

Ответ состоит из двух частей:

Решение вопроса

Ваша установка Phing должна выполняться с помощью composer. Сделайте composer require phing/phing - и тогда вы можете использовать vendor/bin/phing для запуска вашего build.xml файла (вместо, скажем, глобальной установки).

Тогда, когда вы закончите, ваш последний шаг для запуска может быть composer remove phing/phing

Предлагаемый рабочий процесс

Итак, идея с чем-то вроде Дженкинса заключается в том, что вы должны использовать его для выполнения всей сборки и обработки в системе сборки. Затем он (Дженкинс) - это инструмент, который может сделать для вас все что угодно в удаленных системах. Таким образом, вместо того, чтобы звонить на развернутый сервер и затем выполнять его задачи, вы бы сказали Jenkins выполнять эти задачи удаленно. (Это может быть выполнено с помощью каждого шага, требующего повторного подключения к серверу для выполнения нового шага). Поскольку эти шаги также являются частью процесса развертывания, в случае сбоя любого из них сборка будет считаться неудачной, и вы получите это представление. Итак, как говорится, решение, которое я предлагаю, выше, но я бы порекомендовал изменить все остальное.