Обнаружение проблем разработки пути к производственному серверу - PullRequest
2 голосов
/ 11 августа 2010

У нас есть сервер разработки, который мы используем при разработке приложений LAMP.

У нас также есть рабочий сервер, на котором развернуты наши веб-сайты.

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

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

2) Другой вариант - мы можем запретить любому внешнему веб-сайту ссылаться на изображения на сервере разработки.,(http://altlab.com/htaccess_tutorial.html). Любые ссылки на изображение на сервере разработки могут быть заменены изображением с надписью «НЕПРАВИЛЬНЫЙ ПУТЬ» и т. Д.

Какие есть еще варианты?

(Примечание: я согласен, что цель состоит в том, чтобы ПРЕДОТВРАТИТЬ проблемы с этими путями в первую очередь на производственном сервере, что можно сделать с помощью инструментов управления версиями и развертывания кода и т. Д. Однако в этом разговоре я специально искал способыобнаружение проблем с этими путями. Это дополнительный уровень контроля качества, который я ищу ...)

Ответы [ 8 ]

1 голос
/ 29 сентября 2010

Вы должны поместить зависящие от среды настройки в конфигурацию виртуального хоста. Поместите это

SetEnv IMAGE_PATH = '/var/www/images/'

внутри виртуального хоста НА производственном сервере.

В вашем PHP-коде используйте

getenv('IMAGE_PATH')

чтобы получить путь

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

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

0 голосов
/ 28 декабря 2010

не ждите ошибок.

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

вы можете даже использовать те же утилиты для замены.

0 голосов
/ 23 сентября 2010

Я бы согласился с banzaimonkey, кроме как начать с гусеничного шасси.Работа с журналами веб-сервера предполагает, что к проблемным изображениям, таблицам стилей и т. Д. Обращаются с некоторой регулярностью.Страницы или ссылки, расположенные глубоко на сайте или на редко посещаемых страницах, могут быть легко пропущены.Просматривая страницы, вы должны найти их надежно.

Я ни в коем случае не эксперт, но я работаю над несколько схожей проблемой.Мое решение состояло в том, чтобы использовать Perl и модуль WWW :: Mechanize для сканирования целых сайтов и записи различных аспектов страниц.В моем случае я хотел список плохих ссылок, определенных форм, мультимедийных объектов и еще около пяти других вещей.Мне удалось создать сценарий, чтобы он относился к определенным хостам как к «локальным» (в ряде доменов существует около 80 сайтов).Вы должны быть в состоянии сделать то же самое в обратном порядке, идентифицируя «плохие» ссылки.Это предполагает, что вы проводите тестирование ПОСЛЕ развертывания рабочего сайта.Возможно, вы могли бы сделать какой-то вариант, который позволил бы выполнить проверку перед развертыванием.

Другой альтернативой было бы посмотреть на уже написанный сканер и посмотреть его результаты.Интернет-архив выпустил Heritrix , который сканирует, архивирует и создает отчеты на веб-сайтах.Это, вероятно, немного излишним.Опция, подобная LinkChecker , может быть использована с опцией verbose, тогда вывод выводится для экземпляров имени / IP-адреса сервера разработки.Я уверен, что есть много других вариантов в этом направлении.

Я упоминаю их прежде всего потому, что я думаю, что вы хотите что-то, что автоматизирует процесс больше, чем кто-то проверяет каждую страницу вручную.Эти инструменты могут занять некоторое время, так как они пересекают весь сайт, но они могут дать довольно полную картину.Основными вещами, с которыми я плохо справляюсь, являются javascript и формы.Heritrix фактически обрабатывает некоторые ссылки JavaScript, но все еще не обрабатывает формы.

Тем не менее, WWW :: Mechanize и другие модули могут программно отправлять формы, но им должны быть заданы конкретные значения.В вашем случае, если у вас большая база данных, вам может потребоваться отправить только одно или два значения формы для проверки изображений и т. Д. Не с сервера разработки.С положительной стороны, вы также можете проверить возвращаемый контент, чтобы убедиться, что формы работают правильно.У меня сегодня была проблема с постраничной навигацией - страница показала те же 20 результатов независимо от выбранной страницы.Проверка этого может быть автоматизирована путем тестирования определенных строк в наборах результатов (это входит в область разработки, управляемой тестами).

Еще одна вещь - Heritrix фактически создает архивы.Это основа для WayBack Machine в интернет-архиве.Вы можете получить дополнительное преимущество, если хранение нескольких версий веб-сайтов представляет интерес для вас или вашей организации.

0 голосов
/ 20 сентября 2010

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

0 голосов
/ 21 августа 2010

Обычно я проверяю, чтобы пути на рабочих станциях разработки и сервере промежуточного тестирования не были одинаковыми.Например, на рабочей станции разработчика это localhost / websitename / path, а при установке его просто websitename / path.

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

Да, я 'м при условии, что контроль версий, процедура развертывания и т. д.

Да, поиск / замена, grep, пауки - все ваши друзья, чтобы исправить гнездо крыс, которое вы начали с вкладки Firebug .NET, также полезно

0 голосов
/ 11 августа 2010

Логи Apache

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

Базовые журналы apache должны содержать IP-адреса компьютеров, запрашивающих файлы на каждом сервере. Вы должны иметь возможность отфильтровывать любые IP-адреса, которые вы или ваша команда используете, и видеть, какие файлы на сервере разработки извлекаются внешними IP-адресами.

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

Самоанализ

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

Первый вариант - использовать инструмент поиска ( grep или grepwin ) в вашем коде и буквально искать домен dev в вашем коде. Если вы используете сложный код для объединения доменов, это может не сработать, но если вы просто жестко закодировали значения повсюду, это может быть волшебной пулей.

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

0 голосов
/ 11 августа 2010

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

<?php

include_once(FS_ROOT . 'lib/foo.php');
echo '<link href="' . WEB_ROOT . 'css/bar.css" rel="stylesheet" type="text/css">';

?>

Эти константы могут быть установлены в неверсионном файле:

define('FS_ROOT', '/home/project/htdocs/');
define('WEB_ROOT', '/');

... или может быть вычислено динамически с помощью __FILE__, $_SERVER['DOCUMENT_ROOT'], dirname() и подобных вещей.

0 голосов
/ 11 августа 2010

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

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