Разверните веб-приложение на подготовке - производство с подверсией
Это, кажется, вызывается при наличии сервера, который имеет имя дольше, чем 15 символов. Более длинное имя является усеченным netbios и заканчивает тем, что вызвало эту ошибку.
Решение, удостоверяются, что Ваши названия машины находятся под 15 символами.
Подверсия является системой управления версиями не система развертывания. Не используйте его. Так как Вы делаете все ручное прямо сейчас (здание и тест), я также развернулся бы вручную, который может также означать, что Вы пишете некоторые сценарии, которые проверяют правильную версию из подверсии и развертывают ее на любой среде, к которой Вы хотите это.
Если бы Вы хотите автоматизировать больше, я рекомендовал бы сервер CI или своего рода решение для развертывания для этого. Мы начинаем использовать Гудзон для тестирования и развертывания (по крайней мере, для среды песочницы). Мы не намереваемся использовать его для производства. Поскольку мы еще не зарегистрировались в плагине продвижения. При исследовании серверов CI я заметил, что коммерческие системы обычно предлагают лучшую поддержку управления версиями.
-
1Управление веб-сайтом от SVN довольно распространено. It' s даже в FAQ: subversion.tigris.org/faq.html#website-auto-update – Gerald Combs 23 December 2009 в 22:29
-
2Несмотря на это, это рекомендуется, я, вероятно, не использовал бы его для производства. Для тестовой среды не проблема, для производства необходимо удостовериться, что полномочия установлены правильно так, чтобы только правильные люди могли развернуться. Однако он говорит о команде двух разработчиков. Здесь это могло бы быть излишество для реализации некоторого большого решения. Управление правами может быть сделано на все или ничего основание также. – Peter Schuetze 23 December 2009 в 22:50
Существует несколько способов, которыми можно сделать это:
Используйте сервер сборки
Я услышал о командах, использующих CCNET.net или Сервер FinalBuilder для этого. В основном, что происходит, то, что сценарий сборки имеет код для продвижения последней сборки, каждый раз, когда кто-то делает регистрацию. Я не рекомендовал бы это для производства все же. Это должно хорошо работать для среды подготовки все же.
Я не очень знаком с серверами сборки на Linux, но я знаю, что существуют некоторые. Существует также Муравей, и даже Сделайте сценарии, которые могли использоваться для этого.
Поместите рабочую копию на сервер подготовки
Просто сделайте выезд и отобразите корректную папку, чтобы быть корнем веб-приложения. Кто-то в команде должен будет вручную обновить эту рабочую копию, но это дает Вам гибкость для возвращения к предыдущей версии при необходимости.
Протесты
Необходимо будет удостовериться, что Вы исключаете .svn папки когда Вы указывающий на веб-сайт на рабочую копию.
Я не рекомендовал бы использовать сценарий рычага Подверсии для этого. Можно в значительной степени использовать любой механизм выполнения сценариев, настолько доступный в Linux, чтобы сделать сценарии постфиксации. Я ввел "сценарий рычага постфиксации Linux" в Google и получил некоторые хорошие хиты.
Этот вопрос является действительно вопросом о процедурах выпуска (и инструменты), а не системное администрирование, но здесь является моим лучшим ответом:
Любая последняя версия Подверсии проявляет превосходную заботу о Ваших потребностях управления конфигурацией, но, как Peter сказал, это не инструмент развертывания. Одна опция состояла бы в том, чтобы встроить развертывание в Вашу регулярную инфраструктуру сборки (например, 'делают, развертываются'), и управляйте своими правилами развертывания вместе с Вашим кодом.
С точки зрения управления конфигурацией необходимо отслеживать все, что приложение должно функционировать, включая код, внешние библиотеки (в определенных версиях), веб-сервер, версии ОС, и т.д. 'делают, развертываются', должен попытаться гарантировать, чтобы все те вещи существовали, прежде чем это попытается развернуть новую версию.
Инструменты как Гудзон могут также обработать развертывание для Вас, но необходимо будет все еще сказать это, что сделать, и я просто предпочитаю сохранять свои процедуры управления конфигурацией максимально простыми. Один пример состоял бы в том, чтобы позволить Гудзону вызвать 'make deploy', но не хранить никакую другую информацию в Гудзоне, который необходимо было бы восстановить для воссоздания на дополнительных машинах.
Как часто будут Вами делающий выпуски, которые должны быть развернуты? Я рассмотрел бы что-то вроде меток Вашего веб-приложения в теги / и наличие механизма постфиксации, который знает, что tags/webapp-1.0.4 должен быть экспортирован в Ваш webroot. Если Ваше веб-приложение является большим, полагайте, что наличие рычага отбрасывает специальный файл в/tmp, который cronjob проверяет каждую минуту и принимает соответствующие меры на.
Если Вы хотите более подробный ответ, уточните свой план выпуска, размер кодовой базы, выбор языка, среды ОС и зависимостей.
Мы также используем Subversion для управления нашим источником, но используем Webistrano для развертывания из Subversion на наши серверы.
Webistrano - это веб-интерфейс для Capistrano , популярный инструмент развертывания и автоматизации в сообществе Ruby. Он позволяет описывать процесс развертывания в сценариях Ruby (большая часть функций встроена). Он довольно гибкий и понятный. Развертывание и откат развертывания просты, как и подключение других задач, которые необходимо выполнить, например очистки кешей или миграции баз данных.
Я смог это сделать, создав свежий файл post-commit со следующими двумя строками:
#!/bin/bash
ssh -i /path/to/key-file -pSSH-PORT user@hostname svn update /path/to/project/folder/