Какой лучший способ безопасно опубликовать сборку сообщений сайта?

Для некоторых проектов я использую Capistrano , чтобы заставить жить. Он построен на вершине ruby и делает развертывание сценария написания супер легко и использует ssh.

В других проектах у меня есть крошечное приложение для развертывания, которое использует bash для экспорта svn во временный каталог, а затем rsync на живой сервер. Вы можете сделать rsync использовать ssh.

Я очень предпочитаю метод Капистрано, даже если ваш проект не находится в ruby/rails.

Это похоже на то, что можно легко сделать с SFTP. Взгляните на PuTTY (программе pscp и psftp) или WinSCP для Windows, или rsync и OpenSSH на Юниксах.

Я поддержу рекомендацию для Capistrano, хотя, если вы ищете решение на основе GUI, вы можете попробовать интерфейс Webistrano. Чистая, основанная на ssh, здравая семантика deployment и отката, а также простые сценарии и расширяемость через ruby.

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

В bash:

#!/bin/bash

set -e
cp -R /var/livesite /var/newversion
rsync user@devserver:/var/readytogolive /var/newversion
mv /var/livesite /var/oldlivesite
mv /var/newversion /var/livesite

Виола!

Редактировать: @Ted Персиваль-это хорошая идея. Я даже не знал о "set -e". Обновленный скрипт. Edit: обновлено снова по предложению Ted (хотя я думаю, что это все равно сработает, если каким-то образом команда cp потерпит неудачу, и если cp потерпит неудачу, у вас, вероятно, будут более серьезные проблемы.)

@Neall, я бы добавил set -e на второй строке, потому что вы не хотите, чтобы живой сайт был заменен, если rsync не работает по какой-либо причине. set -e вызывает выход скрипта, если какая-либо из его команд завершается ошибкой.

Редактировать: set -e должно быть первым делом в скрипте, сразу после #!/bin/bash .

На внештатной работе, которую я сделал, мы создали три отдельных окружения.

• Dev-сервер, который запускал продолжение сборки с использованием CruiseControl. Любая Регистрация вызовет сборку. Тестирование качества было сделано здесь.
• Тестовый сервер, на котором проводилось приемочное тестирование пользователя.
• Производство.

Рабочий процесс был следующим:

1. Разработчик проверяет изменения в SourceControl.
2. CruiseControl создает и развертывает сборку в Dev.
3. Дев QA объед
4. После передачи QA запускается сценарий robocopy, который развертывает сборку Dev для тестирования.
5. Тест UAT объед
6. После прохождения теста запускается сценарий robocopy, который развертывает тест в PRD.

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

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

hm, здесь мы используем staging "server" для тестирования в живой среде (фактически, его виртуальный хост apache на рабочем сервере) и araxis merge (действительно умный инструмент сравнения файлов line-by-line) для синхронизации разработки и постановки.

после его тестирования, просто; замените файлы на рабочем webroot :)

/mp