Всем привет. Я столкнулся с проблемой при разработке в Discourse.
Обычно я клонирую файлы из Git,
вношу изменения,
делаю коммит в Git.
Мой коллега делает git pull
и получает все мои изменения.
Как я могу реализовать что-то подобное в Discourse?
Как внести изменения так, чтобы другие люди могли установить их у себя дома?
Если вы разрабатываете тему или плагин для Discourse, оба могут быть размещены в Git-репозитории без проблем.
Спасибо за ответ. Да, вы правы насчет темы. А как насчет синхронизации компонентов и настроек?
Код вашего плагина может определять миграции и/или начальное наполнение при необходимости. Он также может гарантировать, что настройки сайта имеют соответствующие значения.
Я хочу полностью клонировать свою установку
Вы можете создать резервную копию и восстановить данные там, где это необходимо.
Я предпочитаю использовать S3 для резервного копирования, и тогда все сайты могут использовать один и тот же набор резервных копий. Затем, когда вы создаете резервную копию на продакшене, вы можете сразу же восстановить её на своих staging-средах, чтобы убедиться, что всё работает с актуальными данными.
Что такое S3? Я хотел бы это использовать
Использование объектного хранилища для загрузки файлов (S3 и клоны) и Настройка загрузки файлов и изображений в S3 — это с чего стоит начать. Для создания резервных копий процесс довольно прост.
Backblaze и Wasabi — недорогие решения. Также есть продукт от Storj.io, который я использовал для резервного копирования.
Мое скромное мнение, и я не хочу умалять полезность комментариев здесь о резервных копиях, но если отойти на шаг назад: я действительно не уверен, что «синхронизация» установок Discourse стоит больших усилий.
Если вы не планируете делать pull-реквесты в ядро Discourse, то разработка плагинов или компонентов тем (TC) — это то, что нужно, и это дает наиболее надежное и эффективное решение для кастомизации.
Главное в разработке плагинов и компонентов тем (TC) — они будут развертываться на нескольких экземплярах Discourse, над которыми вы, возможно, в любом случае не имеете контроля.
Так что наличие слегка уникального локального экземпляра Discourse для разработки — это вполне нормально (в разумных пределах).
Основной рабочий процесс должен включать обновление плагина или TC в общем репозитории, скорее всего, на Github.
Я полностью согласен. У меня есть несколько клиентов с кастомизациями, которые невозможно проверить (или проще всего проверить) на их реальных данных, поэтому им очень важно видеть сайт с актуальной информацией.
Да, это справедливо. Это зависит от того, что вы пытаетесь сделать и кто ваша клиентская база (одна целевая аудитория или несколько клиентов?) и насколько большим контролем вы планируете обладать.
Спасибо всем за ваши советы. Скорее всего, я буду использовать PRing в ядро Discourse. Поэтому мне нужна возможность загружать сборку в git, а оттуда — на сервер.
Если вы отправляете PR в ядро Discourse, то точная конфигурация локальной установки не критична (просто убедитесь, что у вас последняя версия), поскольку процесс внесения изменений в код и так строго контролируется, особенно с учётом тестовых случаев. Поэтому небольшие расхождения в настройках или содержимом вряд ли станут проблемой.
Обычно при совместной работе над вкладом вы сначала форкаете репозиторий вашей организации и работаете там, а затем отправляете PR?
Нет, я не работаю над совместными вкладами. Я работаю для личного использования.
Я не хотел так это формулировать.
Как я могу установить Discourse из форка Git?
Я внесу изменения в ядро Discourse и добавлю их в свой репозиторий на Git.
Я не совсем понимаю, зачем нужно синхронизировать ваши установки?
Просто выполните git clone вашего форка.
Обычно для разработки Docker не используется, но если вы его используете, вы можете войти в контейнер и проверить свой форк.
Например.
Сейчас я настроил Discourse.
Затем, когда всё готово, я обновляю свою сборку.
После этого я снова продолжаю разработку. Я меняю некоторые настройки в панели управления. Их может быть очень много.
Когда я захочу обновить свою сборку, мне также понадобится обновить настройки.
В этом случае мне придётся вручную настраивать параметры.
Настройки сохраняются, и вы работаете в одиночку, так зачем же уделять внимание резервному копированию и синхронизации?
(Кроме того, название темы тогда сбивает с толку: зачем «в команде»?)
При клонировании или переключении на другую версию вы не очищаете базу данных (где хранятся настройки).
Вы сами решаете, когда запускать миграции (если они вообще есть). В противном случае база данных должна оставаться стабильной.
