Я бы посоветовал избегать перемещения файлов из одной среды в другую и приступить к реализации пакета-кандидата на выпуск.
Эти пакеты могут быть получены с помощью простого средства архивации (tar, winzip) или более сложных, таких как Wise Installer или InstallShield.
Цикл будет выглядеть примерно так:
- сборка кандидата на выпуск из ветви тега кандидата на выпуск, включающей объединенные наборы изменений, готовые пройти через тестовую группу,
- упакует ВСЕ файлы из сборки в tar / zip / setup.exe
- развертывание в различных средах тестирования через один и тот же пакет
- если кандидат на выпуск прошел тестирование, тот же пакет можно использовать для развертывания в рабочей среде; если нет, вернитесь к исходной точке и соберите другого кандидата.
Если кандидат на выпуск не удался, тогда кандидат назначается несостоявшимся базовым планом, исправления внедряются, а другой кандидат на выпуск создается и упаковывается.
Хотя я, как правило, не одобряю помещение встроенных объектов в репозиторий исходного кода, с точки зрения удобства и контроля пакет можно поставить под контроль, чтобы гарантировать, что в него не будет внесено никаких изменений между временем использования пакета для развернуть из одной среды в другую.
Идентификатор версии-кандидата для выпуска должен использоваться в соглашениях об именах для пакета и соответствующей ветви кода, чтобы обеспечить очевидные взаимосвязи. Если возможно, размещение информации об идентификаторе версии в файлах ресурсов помогает гарантировать, что файлы из правильной сборки находятся в правильном месте.
Я предпочитаю собрать все и развернуть все, даже если изменился только один файл. Сборка, упаковка и развертывание всего, что позволяет каждый раз сохранять сценарии и процессы простыми и воспроизводимыми.
В основном ... построить один раз, развернуть часто.