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

Question

Итак, по вашему опыту, как лучше? Есть ли безопасный способ, который также можно использовать для сценариев / запуска в инструменте автоматизации сборки?

Редактировать: я должен упомянуть, что это windows / .net, и я буду развертывать на iis6

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

Сделайте копию своего каталога живого сайта, используйте 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

Viola!

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

Answer 6

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

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

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

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

Answer 7

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

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

/ * т.пл. 1007 *

Answer 8

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

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