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

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

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

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

Ответ 1

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

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

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

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

(Предположим, что у вас есть приложение в /usr/local/application/current)

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

Чтобы обрабатывать закачки, классическое решение состоит в том, чтобы переместить фактическую директорию из основного веб-пространства, оставив ее только для новой версии, которая будет проверена (как я уже делал в script ниже), а затем используя Apache для ' Псевдоним "он снова встал на место как часть веб-сайта.

Alias /uploads /home/user/uploads/

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

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

#!/bin/sh

REV=2410
REVDIR=$REV.20090602-1027

REPOSITORY=svn+ssh://[email protected]/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 затем имеет doc-корень из... /website/dev/htdocs/

Также есть соответствующий... /website/live/htdocs/docroot, и снова "live" - это еще одна символическая ссылка. Это мой другой script, который удалит живую символическую ссылку и заменит ее на все точки 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 не хотел бы больше, чем несколько версий сайта), но для меня я считаю, что это очень проблематично для моего собственного развертывания.

Ответ 7

проверить фредистрано, это клонирование capistrano отлично работает (litle bit запутывает установку, но после всех работает отлично)

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

Ответ 8

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

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

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

script 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

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

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

Ответ 9

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

Где я работаю, все будет проверено в репозитории для просмотра и затем будет выпущено.

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

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

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