Дмитрий Пелевин
@mrFleshka
Team Lead / Senior PHP Developer
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Team Lead / Senior PHP Developer
Information
Когда много динамики в выдаче (эти блоки мы ему уже показывали, сегодня покажем эти), это контролирвоать очень трудно. Отсюда и кэш плодится, как незнамо кто…
Пока доверяю простым запросам к БД, которые должны сами по себе кэшироваться и простой шаблонизации/сериализации, но только для AJAX запросов. Основные страницы всё же из кэша.
А так да, можно сделать составные ключи, но я вот чувствую, что работать с ними слишком больно…
Но проблема всё равно оставалась, т.к. на сайте все данные передаются по API и его я кэшировать не могу. API завязан на данные пользователя и ответ в некоторых случаев разный для разных пользователей. Вот что с API делать — загадка.
У меня так, думаю кому-то будет полезно, если схожая ситуация.
Даже выделил (см. пункт «Итог»).
Но даже не в «срочно» смысл, просто неохота поднимать окружение на всех машинах. Да, и такое бывает. Не переводите всё на промышленные масштабы)
Говорю же, срочно что-то поправить в рабочем сайте.
При чём тут докер или вагрант?
Да, на ноутбуке жены в поездке стоит всё окружение и настроен деплой)))))
Да и чес слово, ну проще же поставить один раз это всё на сервак, чем потом разбираться что на другой машине ещё и ноды нет, а последняя нода не билдит то что нужно и т.д.))
Жёстких требований к «отсутствию билда на сервере!» не было, поэтому почему бы не попробовать))
— Можно ли этот процесс легко перенести на другую машину?
— А что если на самом сервере нужно сделать правки, не имея IDE под рукой?
— А заливается автоматически (ярый противник автоматического деплоя, особенно при работе с боевым сервером :D)?
Просто именно с такими трудностями столкнулись я и мои друзья при работе над сайтом при «заливке готовых ресурсов на боевой»…
Серёжа знает CMSку и готов покодить немного, Юра может чото поверстать, но дико далёк от PHP и системы. Вместе они делают какой-то сайт для подруги жены Серёжы… Я бы не парился там с деплоем, но скрасить время вёрстки для Юры я не откажусь)
Можно и заморочиться, но я вижу больше плюсов в таком подходе (читать как «более простом»).
Процесс деплоя тянет за собой одеяло с целой кучей проблем, к которым система может быть не готова, всё зависит от изначально выбранного подхода.
— Нет деплоя, есть админка, работаешь прямо на сервере? Статья для тебя.
— Хочешь автоматизировать деплой и не ставить на сервер инструменты для билда? Ищи другой подход, статья не об этом.
Как-то так.
Не вижу смысла спорить, всё что вы говорите верно, и, конечно, на много удобнее на крупных проектах с командой, но повторюсь, это пример реализации для конкретного процесса разработки и поддержки сайта (не процесс разработки сайта то обсуждать нужно).
Пользователь там один, а правки могут делать как программист, так и верстальщик.
Может ещё можно придумать, но это действительно неудобно. В таком процессе работы может даже и не быть Git'а совсем…
В данном случае мы живём лишь в рамках IDE и админпанели, которая за нас частично автоматизирует процесс. Просто и удобно (основной акцент на «просто»).
— верстальщик правит один файл, а ему нужно заливать другой.
— верстальщик забывает залить все SCSS файлы на сервер, от этого страдают потом все.
— верстальщик не в состоянии адекватно настроить генератор на разных машинах (плохой аргумент, но и такое было)
— программист не хочет настраивать генератор и вообще лезть во фронтенд, но необходимо сделать мелкую правку. Здесь и сейчас…
Я не считаю интеграцию с PHP или установку NodeJS на сервер проблемой. Это (как и все остальные проблемы) задача, которая требует решения, возникшая во время выполнения другой задачи)
Прошу, не рассматривайте это как позыв к действию: «Как начать писать свой проект… с галпом через админку», это лишь попытка помочь тем, кто уже использует такой процесс разработки, либо просто не нуждается в чем либо более современном.
Конечно это не туториал для профессиональных разработчиков мощных систем, но вот помочь связке Программист + Верстальщик, работающим с одним сайтом (каким-нибудь там dev.mysite.ru) это несомненно может.
Мой пример подходит для совсем лайтовых систем, которые не висят на автоматизированных Build & Deploy системах и, скорее всего, поддерживаются одним человеком.
Вряд ли для личного мини сайта или блога вы будете писать проект с использованием CI, но мелкие правки вы предусматриваете в будущем.
А если привык к хорошему (Gulp), то частичку этого можно и оставить, пусть и таким образом)
Кстати, отмечу, что даже не все свои проекты я запускаю с выгрузкой собранных сырцов. Некоторые настолько специфичны, что содержат большое количество хотфиксов, которые просто не удобно все билдить заранее, поэтому на продакшете всё же остается возможность запустить билд, хоть это и делает система деплоя)