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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

последнее, что происходит, это старая символическая ссылка .../website/dev / повторно связан с недавно проверенным каталогом. Затем конфигурация Apache имеет корень doc .../ веб-сайт / 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 не хотел бы больше, чем несколько версий сайта вокруг), но для меня это очень много проблем для моего собственного развертывания.

после 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. скрипт создает новый каталог в каталоге releases с текущим datetime. Внутри этого каталога ваш код обновляется до указанного вами тега.

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

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

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

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

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

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

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