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

Question

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

Текущий процесс развертывания влечет за собой то, что мы только перемещаем различия между текущей версией SVN и версией SVN последнего развертывания, которая работает безупречно в моем проекте.

Другие проекты жалуются на этот метод и хотят все развернуть, переместить каждый файл из среды разработки в другие среды, такие как тестирование, подготовка или работа в реальном времени.

Руководитель группы Java и руководитель группы PHP согласны с этим. Я разработчик PHP и считаю этот способ неэффективным и бесполезным. Нам не нужно использовать столько времени и пропускной способности, когда мы решаем развернуть, чтобы жить, копируя все.

Когда мы внедряем с использованием различий SVN, администраторы сервера сохраняют сжатый файл, содержащий все измененные файлы, относящиеся к текущему развертыванию, поэтому проще вернуться, когда мы захотим.

Я просто хочу несколько веских причин представить руководителю компании, который технически осведомлен о проблемах процесса развертывания, просто чтобы он понял, что когда что-то запутано после развертывания, это потому, что разработчики этого не сделали это правильно, а не потому, что мы должны развернуть все для того, чтобы все работало. Я хочу убедить его, что развертывание с использованием SVN намного лучше, чем развертывание всего (примитивное копирование / вставка), не полагаясь вообще на SVN.

2

deployment git php project-management svn

Решение

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

Эскиз нашего сценария развертывания (мы используем Git, с помощью Subversion не имеет никакого значения для алгоритма, отличаются только фактические команды). Мы используем рабочую копию (локальный репозиторий с Git) и другой каталог (названный export) где готовится следующая версия живого кода (вид staging Если вы предпочитаете):

обновить локальную копию кода (это git pull за Git или же svn update за Subversion);
очистить export затем скопируйте в него код; мы используем rsync вместо cp потому что проще предоставить ему список каталогов и файлов, которые следует игнорировать (.git, .svn a.s.o.);
применить любые необходимые параметры конфигурации к файлам из export каталог; F.E. мы не храним конфиденциальные данные (пользователи, пароли) в коде, хранящемся в репозитории, а используем значения заполнителей; этот шаг заменяет значения заполнителей фактическими пользователями, паролями, ключами a.s.o.
делать другие необходимые исправления; F.E. мы используем несколько символических ссылок для указания на каталоги, которые содержат данные, загруженные пользователями; в репозиториях кода у нас есть пустые каталоги для них; на этапе исправления эти каталоги удаляются из export затем создаются символические ссылки с одинаковыми именами; символические ссылки указывают на постоянные каталоги, внешние по отношению к корню сети, где хранятся данные; также мы используем символические ссылки на сторонние библиотеки — они не хранятся в репозитории, и их развертывание происходит по другому шаблону (они обычно замораживаются до версии, которой они были при запуске проекта, чтобы избежать несовместимости);
использование rsync с соответствующими параметрами (--archive и другие) сделать живую версию кода идентичной версии, только что подготовленной в локальной версии. export каталог.

2

Скорее всего, проблема, с которой вы сталкиваетесь, заключается не в «постоянном копировании всего», а в действительности из-за выпуска отдельных файловых исправлений в виде выпуска, а не всей сборки в качестве выпуска. Лучше всего собирать артефакты сборки для всего приложения или компонента приложения, и как только вы дойдете до этого момента, не имеет значения, копируете ли вы все файлы или только файлы, которые изменились, поскольку Теперь подробности реализации вашего программного обеспечения для развертывания (будь то элементарная копия файла, FTP, rsync или инструмент корпоративного уровня, такой как продукт моей компании). BuildMaster).

0

Источник

Accepted Answer

(Мне пришлось использовать aswer, потому что в комментариях было недостаточно места)

Интересный вопрос.

Я предполагаю, что Java-разработчики (как и я) просто используются для развертывания всего приложения каждый раз (и то же самое, вероятно, относится к любому типу языка, который не запускается из источников, как PHP вместо этого).

В бывшей компании, где я работал, это был способ выпустить обновление, и поскольку WAR приложения составлял более ста мегабайт, на этот процесс всегда уходило несколько часов, даже когда всего пара классов изменилось.

Вместо этого в компании, где я работаю, они собрали систему, которая работает с различиями, таким образом, как вы описали (хотя файлы классов Java, конечно, должны быть полностью заменены).
Я думаю, что это лучший подход, гораздо проще и легче справиться.

Поскольку PHP опирается на исходные файлы даже во время выполнения, я думаю, что подход, основанный на различиях, такой как тот, который у вас уже есть, лучше. Так что +1 за ваш текущий подход.

Итак, я думаю, что более быстрое развертывание, более простое резервное копирование и другие вещи, которые вы упомянули в своем вопросе, являются достаточными причинами для сохранения нынешнего подхода.

Конечно, важно, чтобы полнофункциональная версия могла быть создана и развернута из SVN в любое время и чтобы она могла заменить соответствующую дельта-версию на сервере без каких-либо ошибок (но я уверен, что у вас это уже есть).

О людях, которые имеют мнение против вашего: попросите их доказать (с примерами из реального мира), где ваш подход ошибочен.

(Может быть, это лучше подойдет на programmers.stackexchange.com?

2