3 ноября 2023 в 13:00
Подскажите плз, как всё-таки правильнее разрабатывать сайт - создаем на локалке и потом обновляем на хостинге (использую nic.ru, обычны хостинг) или сразу пилить на хостинге?
Комментарии
https://t.me/drupal_beginner/85316/87279 - во первых
Советую пообщаться тут, много что за хостинг могут подсказать
При разработке сайта. Вы можете развернуть как вам удобно. На хосте или локально (благо openserver или докер это поможет вам).
При локальной разработке. У вас меньше гемороя с настройкой, т.к. вы настроили 1 раз для себя сайт и изредка там что-то меняете (максимум версию php | mysql ...etc). Вы спокойно отрубаете кэш, включаете дэбаг и разрабатыываете полноценно функционал, который вам нужен. Из минусов - нельзя использовать вебхуки, тут надо на хосте разместить и тестить.
На хосте - если кратко, вероятность того, что какие-то данные, которые вы не хотите показывать, на этапе разработки / доработки на хосте будут показаны в мир.
Или же, если вы создали на хосте и потом уже он пущен в мир. Вам, допустим, нужно доработать сайт - при доработке на хосте вы не даете спокойно работать клиентам или вовсе сломаете сайт - то не есть хорошо.
По этому, на начальных этапад. можно даже чистый проект развернуть на хосте. Сделать клон его и локально дорабатывать. После заливать все на хост и тестировать
Правильно - разрабатывать у себя.
Но это надо знать как развернуть окружение и как в этом окружении работать. Поэтому ничего страшного, если вы пока будете прямо на хостинге разрабатывать на тестовом сайте, а потом переносить на продакшн.
nic.ru - если у вас получилось по прошлой теме там сайт Композером собрать - я очень рад. У меня там нормально сидеть не получалось даже на 7ке.
90℅ делаю на хостинге. Экономится время и деньги.
На хостинге делают за счёт конструкторов.
И с 90% не согласен. Там часть сайтов просто висят как блог. Полноценный, хороший проект разворачивается локально (сюда же и сервера внутри компаний для тестов, на определенных этапах релиза публикуют в свет .
Друпал может и развернут сразу, но вся доработка идёт локально у большинства нормальных девов
Можешь пояснить, как именно экономится время и деньги? По-моему, наоборот. Причём очень сильно наоборот. Во-первых, тебе приходится платить за хостинг, пока сайт ещё не готов. Во-вторых, когда работаешь с кодом, локально ты правишь что-то и сразу видишь изменения, а на хостинг нужно ещё синхронизировать файлы, либо работать через весьма ограниченный текстовый редактор, встроенный в панель управления. В-третьих, локально удобнее использовать отладку. И в-четвёртых, если работаешь над сайтом, у которого уже есть посетители, то в процессе сайт будет часто недоступен или будет неправильно работать или плохо выглядеть, что в принципе неприемлемо.
зависит от задач и условий.
у меня на чтение документации и работу всего 2 часа в день.
у меня 3х точек с которых я работаю. настраивать их все и синхронизировать очень геморно.
перед началом работы делаю общий бекап и те файлы которые меняю.
есть модуль переключающий тему оформления по условиям theme_switcher .
редактирую файлы посредством программы mcedit или vim на хостинге.
xdebug для меня не нужен. стараюсь на php не программировать. даже если программировать то все равно можно на сервере. зависит от степени вовлеченности и подхода.
я вчера сделал ошибку. ввиду забагованности не моего сайта сделал операции на домашнем сайте. потом эти же операции пришлась делать на рабочем сайте. потратил в 2 раза больше времени.
Для синхронизации есть гит. Поработал на одном компе, закоммитил, и запушил, на втором сделал пулл и продолжаешь.
Все так, но. В случае частой смены компов, придется пушить незавершенную работу, плюс синки базы-файлов.
Я так понял, что ТС хочет удаленный сервер разработки 24х7, к которому можно подрубаться из локальной IDE по ssh/(s)ftp.
Ну или поднять там же Web IDE, можно прям в своем гитлабе.
Нет ничего страшного в том, чтобы пушить незавершенную работу. Можно же работать в отдельной ветке. Настройки экспортируются в конфиги, а остальное не нужно. Мой личный опыт показывает, что отсутствие синхронизации базы между разными окружениями - это только плюс. Сразу привыкаешь писать код так, чтобы он правильно применялся к любому окружению, в результате реже происходят непонятки в стиле "не знаю, на моей машине всё ок".
Все так
с пивом и воблой )
в бегете самый дешевый впс стоит 210 в мес. 1ядро, 1гб ram, 10гб диска. вполне шустро работает и композер не спотыкается
Для разработки личных проектов вполне годный вариант, а на домашней машине настроить рабочее окружение для верстки и кода.
Привет.
Тут скорее вопрос удобства и зависит от ситуации. Каждый выбирает свой путь. В своей работе использую следующие подходы:
Вариант 1:
Если разработка с нуля и потом сайт на поддержке остается.
Разработка ведется на локальном сервере. Все наработки коммитятся в гит в тестовую ветку. Из тестовой ветки настроен автоматический деплой на тестовый сервер. На тестовом сервере сайт показывается клиенту перед сдачей.
Когда требуется перенести правки на живой сайт, то сливаем тестовую ветку в мастер ветку и там в ручном режиме запускаем деплой.
Вариант 2:
Если пришел клиент с готовым сайтом на поддержку.
Поднимаю сайт у себя локально, вношу правки, тестирую и потом закидываю просто через ФТП/SSH измененные файлы.
Вариант 3:
Пришел клиент с готовым сайтом, но задачи бывают редко. Локальную копию, как правило не поднимаю. Правки произвожу сразу на живом сайте. Но тут могут быть исключения, зависит от задачи.
Можно вести разработку сразу на сервере, но тогда я бы рекомендовал закрыть сайт базовой аутентификацией, что бы ни кто лишний не мог попасть на сайт.
Чужие сайты на поддержке тоже лучше добавлять в гит - чтобы потом было понятно, что было сделано до, что - после приемки сайта.
Если версия 8+, то сначала беру comoser.json и composer.lock, делаю composer install, коммит, а затем сверху заменяю файлами проекта - сразу тайное становится явным.
Не спорю. В идеале все хранить в гите. Но всегда есть "но..."). Поддержка включает в себя не только разработка новых фич, но и банальные правки в админке сайта. скажем цену у товара поменять).
Самим клиентам без разницы, добавлен в гит их сайт или нет. Им главное результат.
Если взять тот же ModX, то там нечего хранить в гите, все правки делаются через админку. Так называемые чанки, шаблоны, сниппеты и плагины хранятся в базе.
Если взять OpenCart, то можно только тему сайта запихнуть в гит и то вопрос, на сколько это нужно, там бывает 3-6 файлов всего. Остальные правки делаются через разработку модуля или через модификацию файлов ядра через систему OCMOD. Это спец. xml файл, хранится в базе.
Так а где ты модуль разработанный хранить будешь?)) Опенкарт как раз та система, где весь проект целиком надо хранить в гите
можно в гите хранить, ни кто же не спорит)
Поясни пожалуйста. Ну сделал инсталл, импортировал конфиги (или скорее всю БД), залил файлы. Ну вероятно библиотеки, не часто через композер ставят. Зачем остальные "файлы проекта" поверх заливать? на случай хаков в модулях/ядре?
Хаки ядра/контриба, либы скачанные вручную минуя композер, кастом который лежит не на своем месте.
А как проявляется? Типа ты в Гите вообще все файлы хранить и после залива проверяешь что изменилось?
В гите - кроме vendor, web/sites/default/files и остальное по мелочи, типа settings.php, robots.txt.
Хотя, в свете последних событий, безопасники требуют чтобы vendor тоже лежала в гите. И один раз так нашлась папка vendor/vendor.
Есть отличная статья на эту тему https://niklan.net/blog/186
Она 2018 года, но остается актуальной по своей сути. При работе с 10-кой использую именно этот алгоритм. Удобно, быстро.