Как начать развертывание PHP-приложений из хранилища Subversion?

Question

Я слышал фразу «развертывание приложений», которая звучит намного лучше / проще / надежнее, чем загрузка отдельных измененных файлов на сервер, но я не знаю, с чего начать.

У меня есть приложение Zend Framework, которое находится под контролем версий (в хранилище Subversion). Как я могу "развернуть" мое приложение? Что мне делать, если у меня есть каталог «uploads», который я не хочу перезаписывать?

Я размещаю свое приложение через стороннего разработчика, поэтому я не знаю ничего, кроме FTP. Если что-то из этого включает в себя вход на мой сервер, пожалуйста, объясните процесс.

Answer 1

Автоматическое развертывание + запуск тестов на промежуточном сервере называется непрерывной интеграцией. Идея состоит в том, что если вы отметите что-то, что нарушает тесты, вы получите уведомление сразу. Для PHP вы можете посмотреть Xinc или phpUnderControl

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

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

• SSH к производственному серверу. Остальные команды запускаются на производственном сервере через ssh.
• пробег svn export svn://path/to/repository/tags/RELEASE_VERSION /usr/local/application/releases/TIMESTAMP
• остановка служб (Apache, daemons)
• пробег unlink /usr/local/application/current && ln -s /usr/local/application/releases/TIMESTAMP /usr/local/application/current
• пробег ln -s /usr/local/application/var /usr/local/application/releases/TIMESTAMP/var
• пробег /usr/local/application/current/scripts/migrate.php
• запуск услуг

(при условии, что у вас есть заявление в /usr/local/application/current)

Answer 2

Я бы не рекомендовал автоматическое обновление. Тот факт, что ваши модульные тесты пройдены, не означает, что ваше приложение работает на 100%. Что если кто-то зарегистрирует случайную новую функцию без каких-либо новых модульных тестов, и эта функция не будет работать? Ваши существующие модульные тесты могут пройти, но в любом случае эта функция может быть нарушена. Ваши пользователи могут увидеть что-то наполовину готовое. При автоматическом развертывании после регистрации вы можете не заметить в течение нескольких часов, если что-то сделало его живым, чего не должно быть.

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

1) сделать экспорт из последней регистрации 2) Загрузить экспорт на рабочий сервер 3) Распаковать / настроить недавно загруженный экспорт

Я всегда выполнял последние шаги вручную. Как правило, это так же просто, как экспорт SVN, zip, upload, unzip, configure, и последние два шага, которые я просто объединяю, чтобы выполнить пару команд bash. Затем я заменяю корневой каталог приложений новым, чтобы сохранить старый в качестве резервной копии, и все хорошо.

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

Answer 3

Вот отличная статья об использовании Subversion для развертывания веб-проектов - она ​​отвечает на многие ваши вопросы.

http://athleticsnyc.com/blog/entry/on-using-subversion-for-web-projects

Answer 4

В моей компании webdev мы недавно начали использовать Webistrano , который является веб-интерфейсом для популярного инструмента Capistrano.

Мы хотели иметь простой в использовании, быстрый инструмент развертывания с централизованным интерфейсом, подотчетностью (кто развернул какую версию), откатом к предыдущим версиям и желательно бесплатным. Capistrano хорошо известен как инструмент развертывания приложений Ruby on Rails, но не централизован и ориентирован в основном на приложения Rails. Webistrano расширяет его с помощью графического интерфейса, отчетности и добавляет базовую поддержку для развертывания PHP (используйте тип проекта «чистый файл»).

Webistrano сам по себе является приложением Ruby on Rails, которое вы устанавливаете на сервер разработки или промежуточный сервер. Вы добавляете проект для каждого из ваших сайтов. К каждому проекту вы добавляете этапы, такие как Prod и Dev.

Каждый этап может иметь разные серверы для развертывания и разные настройки. Напишите (или измените) «рецепт», который представляет собой скрипт ruby, который сообщает Capistrano, что делать. В нашем случае я просто использовал предоставленный рецепт и добавил команду для создания символической ссылки на общий каталог загрузок, как вы упомянули.

Когда вы нажимаете кнопку «Развернуть», SSH Webistrano на вашем удаленном сервере (серверах) выполняет svn проверку кода и любые другие задачи, которые вам требуются, такие как миграция базы данных, символические ссылки или очистка предыдущих версий. Конечно, все это можно настроить, в конце концов, это просто сценарий.

Мы очень довольны этим, но мне потребовалось несколько дней, чтобы выучить и настроить, тем более что я не был знаком с Ruby и Rails. Тем не менее, я настоятельно рекомендую его для производственного использования в малых и средних компаниях, поскольку он оказался очень надежным, гибким и многократно сэкономил нам первоначальные инвестиции. Не только за счет ускорения развертываний, но и за счет уменьшения числа ошибок / аварий.

Answer 5

Через 3 года я немного узнал о лучших практиках развертывания. В настоящее время я использую инструмент под названием Capistrano, потому что его легко установить и использовать, и он прекрасно справляется со многими значениями по умолчанию.

Основы процесса автоматического развертывания выглядят так:

1. Ваш код готов к производству, поэтому он помечен версией выпуска: v1.0.0
2. Предполагая, что вы уже настроили сценарий развертывания, вы запускаете сценарий, указывая только что созданный вами тег.

3. Сценарий SSH передан на ваш рабочий сервер, который имеет следующую структуру каталогов:

   /your-application
       /shared/
           /logs
           /uploads
       /releases/
           /20120917120000
           /20120918120000  <-- latest release of your app
               /app
               /config
               /public
               ...etc
       /current --> symlink to latest release
   
   Your Apache document root should be set to /your-application/current/public
   

4. Сценарий создает новый каталог в каталоге релизов с текущей датой и временем. Внутри этого каталога ваш код обновляется до указанного вами тега.

5. Затем исходная символическая ссылка удаляется и создается новая символическая ссылка, указывающая на последний выпуск.

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

Answer 6

проверка фредистрано, это клон капистрано прекрасно работает (немного запутанная установка, но в конце концов работает отлично)

http://code.google.com/p/fredistrano/

Answer 7

Для обработки загрузок классическое решение состоит в том, чтобы переместить действительный каталог из основного веб-пространства, оставив его только для извлечения свежей версии (как я делаю в приведенном ниже сценарии), а затем с помощью Apache для «Alias». это вернулось на место как часть веб-сайта.

Alias /uploads /home/user/uploads/

Однако у вас будет меньше вариантов, если вы не обладаете достаточным контролем над сервером.

У меня есть скрипт, который я использую для развертывания данного скрипта на сайтах dev / live (они оба работают на одном сервере).

#!/bin/sh

REV=2410
REVDIR=$REV.20090602-1027

REPOSITORY=svn+ssh://topbit@svn.example.com/var/svn/website.com/trunk
IMAGES=$REVDIR/php/i
STATIC1=$REVDIR/anothersite.co.uk

svn export --revision $REV  $REPOSITORY $REVDIR

mkdir -p $REVDIR/tmp/templates_c
chown -R username: $REVDIR
chmod -R 777       $REVDIR/tmp $REVDIR/php/cache/
chown -R nobody:   $REVDIR/tmp $REVDIR/php/cache/ $IMAGES
dos2unix $REVDIR/bin/*sh  $REVDIR/bin/*php
chmod 755 $REVDIR/bin/*sh $REVDIR/bin/*php

# chmod -x all the non-directories in images
find $IMAGES -type f -perm -a+x | xargs -r chmod --quiet -x
find $STATIC1 -type f -perm -a+x | xargs -r chmod --quiet -x

ls -l $IMAGES/* | grep -- "-x"

rm dev && ln -s $REVDIR dev

Я поставил номер ревизии и дату / время, которые используются для выписанного имени каталога. Середина chmod также делает права доступа к изображениям нормальными, поскольку они также связаны с нашим выделенным сервером изображений.

Последнее, что происходит, это старая символическая ссылка ... / website / dev / связана с недавно извлеченным каталогом. Конфигурация Apache имеет корневой каталог документов ... / website / dev / htdocs /

Там также есть соответствующий ... / website / live / htdocs / docroot, и снова «live» - еще одна символическая ссылка. Это мой другой скрипт, который удалит живую символическую ссылку и заменит ее на то, на что указывает dev.

#!/bin/sh
# remove live, and copy the dir pointed to by dev, to be the live symlink
rm live && cp -d dev live

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

Answer 8

Такого рода вещи вы бы назвали "Непрерывная интеграция". Atlassian Bamboo (стоимость), Sun Hudson (бесплатно) и Cruise Control (бесплатно) - все это популярные опции (в порядке моего предпочтения), которые поддерживают обработку вывода PHPUnit (поскольку PHPUnit поддерживает вывод JUnit).

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

Answer 9

Это зависит от вашего приложения и от того, насколько надежны тесты.

Там, где я работаю, все проверяется в хранилище для проверки, а затем освобождается.

Автоматическое обновление из репозитория не будет для нас разумным, так как иногда мы просто регистрируемся, чтобы другие разработчики могли получить более позднюю версию и объединить там изменения.

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

Есть также проблемы с ветвлением и другими подобными функциями, которые необходимо будет обработать.