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

Question

В настоящее время я разрабатываю php-приложение для благотворительной организации, и сейчас я нахожусь в стадии определения методов развертывания.

Наше приложение использует Zend Framework и Doctrine. Приложение будет развернуто на разных серверах, каждый из которых имеет свой файл конфигурации. Машины являются как Windows, так и Linux (но все с Apache и php 5.2 +).

Источник доступен в хранилище subversion, и мы хотим собрать и сохранить наши пакеты на сервере Linux.

Желательно, чтобы процесс обновления был таким же простым, как и выполнение команды обновления в каталоге приложения, где команда обновления также обновляет базу данных (с помощью сценариев доктрины) и обеспечивает зависимости сред. Эта команда обновления должна быть командой на компьютере (мы не можем подключиться к ним по ssh). Предпочтительно у нас есть возможность загрузить новую версию или предоставить уже загруженный архив с новой версией. (но только загрузка или только тарбол тоже в порядке)

Пакеты с установками и обновлениями (новые версии) также предпочтительно собирать одной командой.

Я немного читал о phar's, pear, phing, но понятия не имею, какой лучший способ сделать это. Сервер непрерывной интеграции на самом деле не нужен, но я думаю об автоматическом развертывании тестовых сред после создания версии.

Первоначально только обновление php-приложения должно быть очень простым, изначально заполнение файла конфигурации при установке может быть выполнено вручную.

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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