Развертывание — PHP Удалить Phing после PROD Deploy

Question

Развертывание — PHP Удалить Phing после PROD Deploy

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

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

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

-1

deployment phing php

Решение

Другие решения

Представьте, что вашему проекту нужно много зависимостей, например 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 Каталог сразу.

0

Источник

Accepted Answer

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

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

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

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

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

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

1