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

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

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

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

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

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

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

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

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

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

<?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 repo, то вы можете просто написать пакетный / bash скрипт, чтобы загрузить последнюю ревизию и создать резервную копию до старой без вмешательства пользователя - вы также можете запустить любые необходимые скрипты таким образом. Другой альтернативой является написание простого интерфейса для этого в PHP, но это зависит от того, насколько простым он должен быть.

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

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

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

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