Как сделать развертывание для приложения php

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

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

Для управления изменениями на живых серверах у меня также есть свои рабочие копии, а не соединительные линии, но ветвь релиза. Вы можете объединить соединительную линию в отделение выпуска, когда будете готовы к выпуску. Это позволит вам протестировать развертывание и убедиться, что оно твердое, прежде чем выполнять его на живых серверах. Он также имеет приятный побочный эффект, дающий вам хорошую реплику версий сайта-релиза в случае, если вам нужно отслеживать проблемы после запуска.

Наконец, в зависимости от интенсивности и времени этих обновлений, вы также можете захотеть, чтобы ваш сценарий обновления перевернул переключатель «под обслуживание», чтобы пользователи были временно удовлетворены надлежащим сообщением, а не сломанным сайтом.

Benjamin Eberlei опубликовал блог несколько недель назад под названием « Попытка двухэтапного подхода PEAR / PHAR для разработки и развертывания» . Он описывает очень интересную и элегантную процедуру для развертывания приложения PHP.

Я использовал подрывную деятельность в качестве инструмента развертывания.

Используйте обновление svn на всех ваших производственных серверах или используйте phing. (Или используйте phing для обновления svn, даже.)

Делает откаты и резервные копии мгновенными. Не забудьте удалить доступ к любым каталогам .svn.

В любом случае, я бы справился с вашими построениями с помощью phing или чего-то подобного. Пусть он запускает ваши тесты, генерирует документы, создает и публикует ваш пакет / архив.

Что касается распространения, вы можете запустить свой собственный сервер PEAR . Обоснование здесь заключается в том, что вы сказали, что хотите, чтобы пользователи загружали обновления, у вас есть как пользователи Windows, так и Linux, и вы хотите обрабатывать зависимости для них. PEAR должен иметь возможность обрабатывать все это с помощью одной команды.

Тем не менее, я бы пошел с простейшей вещью, которая работает и подходит вашим пользователям. Это может быть только tarball, доступный через HTTP, и небольшой скрипт обновления PHP (или финская цель).

Определенно предоставляйте простой способ отката к предыдущей версии. С кодом / конфигурацией вы можете просто сохранить копию. С помощью БД используйте миграцию (что похоже на то, что вы уже делаете.)

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

<?xml version="1.0" encoding="UTF-8"?> <project name="yourprojectname" basedir="."> <target name="deploy" depends="apply-deltas,update-app01,update-app02"> </target> <target name="update-app01"> <sshexec host="app01" username="yourusername" password="yourpassword" trust="true" command="cd path/to/root/directory &amp;&amp; svn update &amp;&amp; php cmd/clear_cache.php "/> </target> <target name="update-app02"> <sshexec host="app02" username="yourusername" password="yourpassword" trust="true" command="cd path/to/root/directory &amp;&amp; svn update &amp;&amp; php cmd/clear_cache.php "/> </target> <target name="apply-deltas" depends="liquibase-prepare"> <updateDatabase changeLogFile="${db.changelog.file}" driver="${database.driver}" url="${database.url}" username="${database.username}" password="${database.password}" promptOnNonLocalDatabase="${prompt.user.if.not.local.database}" dropFirst="false" classpathref="classpath" > <changeLogProperty name="table.name" value="ant_param_table"/> </updateDatabase> </target> <target name="liquibase-prepare"> <path id="classpath"> <fileset dir="${basedir}/libNoPackage"> <include name="**/*.jar" /> </fileset> </path> <taskdef resource="liquibasetasks.properties"> <classpath refid="classpath"/> </taskdef> </target> </project> 

Это далеко не идеальный, но он отлично подходит для нас. Надеюсь, это поможет.

Ссылки:

Apache Ant

LiquiBase

Если у вас есть вопросы, сообщите мне, чтобы я мог обновить answer.t

Возможно, иногда более простой подход работает лучше всего. Если вы сохраняете стабильные выпуски, которые просто помечены в репозитории svn, вы можете просто написать сценарий batch / bash для загрузки новейшей версии, в то время как резервное копирование до старого без вмешательства пользователя – вы также можете запускать любые сценарии, необходимые для этого. Другой альтернативой является написание простого интерфейса для этого в PHP, но это зависит от того, насколько просто он должен быть.