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

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

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

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

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

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

хм, здесь мы используем промежуточный «сервер» для целей тестирования в реальной среде (фактически, это виртуальный хост apache на производственном сервере) и араксис слияние (действительно умный инструмент построчного сравнения файлов) для синхронизации разработки и постановка.

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

/ мп

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

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

В 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 Percival - Хорошая идея. Я даже не знал о "set -e". Обновленный скрипт. Обновлено: обновлено снова по предложению Теда (хотя я думаю, что он все равно будет работать, если каким-то образом команда cp не удалась, а если cp не удастся, у вас, вероятно, будут более серьезные проблемы.)

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

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

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

На моей внештатной работе мы создали три отдельных среды.

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

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

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