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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

Ты сказал, что у тебя кластер. Мы находимся в том же положении, и мы используем 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

Ответ 6

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