Как создать надлежащий веб-сайт? [закрытый]
3 ответа
Вы правы, при развертывании масштабируемого веб-сайта все может усложниться. Вот несколько хороших рекомендаций (отказ от ответственности: я инженер по рельсам):
Большинство решений, касающихся файловой структуры вашего репозитория кода, в значительной степени основаны на соглашении о языке, структуре и платформу, которую вы выбираете для реализации. Многие из поднятых вами вопросов (JS, CSS, ресурсы, производство и разработка) решаются с помощью Rails. Однако это может отличаться от PHP к Python и от любого другого языка, который вы хотите использовать. Я обнаружил, что вам следует провести небольшое исследование о том, какой язык вы выбираете для использования, и попытаться найти способ соответствовать соглашению этого сообщества. Это поможет вам, когда вы позже попытаетесь найти помощь при преодолении препятствия. Ваш код будет организован так же, как и их код, и вам будет проще получать ответы.
Я бы контролировал версии всего, что не очень велико по размеру. Единственная проблема, которую я обнаружил с VC, - это когда ваше репо становится большим. Кроме того, я ни разу не пожалел, что сохранил версию предыдущего кода.
Для развертывания на нескольких серверах существует множество сценариев, которые могут помочь вам выполнить то, что вам нужно. Для Ruby / Rails наиболее широко используемым инструментом является Capistrano. Есть аналогичные ресурсы и для других языков. В основном вам просто нужно настроить настройку вашего сервера, а затем написать или посмотреть в открытый исходный код для набора скриптов, которые могут развертывать / откатывать / управлять вашей кодовой базой на серверах, которые вы указали в своем файле конфигурации.
Разработка и производство - это важное различие.Хотя вы можете работать без этого различия, это быстро становится громоздким, когда вам приходится исправлять код во всем репозитории. На вашем месте я бы написал код, который запускается в начале каждого запроса и определяет, в какой среде вы работаете. Тогда вы получите эти знания, когда будете обрабатывать этот запрос. Эту информацию можно использовать, когда вы указываете, какую конфигурацию вы хотите использовать при подключении к своей базе данных, вплоть до отображения отладочной информации в браузере только при разработке. Пригодится.
RESTful во многом определяет то, как будут обнаруживаться страницы вашего сайта. Попытка сохранить ваш код в спокойной структуре помогает вам помнить, где находится ваш код, обеспечивает предсказуемость вашей маршрутизации, предохраняет ваш код от излишне связанного и следует соглашению, которое становится все более и более приемлемым. Очевидно, существуют и другие соглашения, которые могут достичь тех же целей, но у меня был большой опыт использования REST, и он существенно улучшил мой код.
Все, что было сказано. Я обнаружил, что, хотя у вас могут быть хорошие намерения создать безупречную кодовую базу, которая может бесконечно масштабироваться, приятная и чистая, это редко получается. На вашем месте я бы провел небольшое исследование того, что вам удобнее всего и что поможет облегчить вашу жизнь, и согласился бы с этим.
Надеюсь, это поможет!
Хотя у меня мало опыта работы с инструментами вы упомянули, за исключением MySQL, я могу дать вам несколько довольно стандартных ответов на заданные вами вопросы.
1) Зависит от деталей, но чаще всего вы храните их в том же репозитории, но в отдельной папке.
2) Тот факт, что что-то зафиксировано в репозитории, не означает, что он готов к запуску - довольно часто это промежуточная сборка, в которой могут быть обнаружены ошибки. Публикация выполняется вручную с экспортом из репозитория. Настройка веб-сервера в той же папке, что и svn checkout, - это огромная проблема, поскольку папка .svn содержит довольно много конфиденциальной информации, например, о том, как отправить изменения на svn-сервер.
3) Вы используете какое-то решение NAS или SAN или просто сетевой ресурс на одном из серверов и читаете оттуда все свои данные. Таким образом, когда вы отправляете информацию в одно место, она становится доступной для всех серверов. Если ваша сеть работает медленно, вы настраиваете сценарии, которые автоматически отправляют файлы на все серверы из одного места. Если вы используете многосерверную среду в ASP.NET, не забудьте обновить машинный ключ в файлах конфигурации, иначе ваши общие зашифрованные кеши, такие как состояние просмотра, не будут работать на серверах. Также неплохо иметь хранилище сеансов в базе данных.
4) У меня есть этап пост-сборки, который запускается только при публикации, который заменяет мои строки подключения к базе данных на производственные, а также меняет значение конфигурации моего производственного приложения с false на true в опубликованных файлах web.config / app.config. . Я не вижу случая, чтобы вам понадобились разные файлы конфигурации для разных серверов, обслуживающих один и тот же контент.
Если что-то непонятно, прокомментируйте, я постараюсь уточнить.
Удачи! // Эрик Йоханссон
Я думаю, вы смешиваете два разных аспекта: управление исходным кодом и развертывание. Тот факт, что все ваши файлы хранятся в одном репозитории, не означает, что их нужно развертывать таким образом. Также спорно, следует ли развертывать напрямую с использованием системы управления версиями или вместо этого использовать сценарий сборки / развертывания, который может обрабатывать любое количество конфигураций.
Кроме того, размещение статических файлов в отдельном домене действительно имеет смысл только на веб-сайтах с высокой посещаемостью. Вы уверены, что не выполняете оптимизацию раньше времени?