Skip to content

Latest commit

 

History

History
184 lines (157 loc) · 11.1 KB

development.md

File metadata and controls

184 lines (157 loc) · 11.1 KB
Raw

Разработка

Разворачивание локально:

Предполагается, что у вас уже установлены:

и вы добавили ssh-ключ на GitHub (инструкция).

Допустим все ваши проекты лежат в ~/projects (или замените на свой путь):

cd ~/projects
mkdir lord-server
cd lord-server
# не забудьте предварительно добавить на GitHub свой публичный ssh-ключ
gh repo fork lord-server/lord --clone -- --recurse-submodules
cd ~/.minetest/games/
ln -s ~/projects/lord-server/lord

Проверить:

cd ~/projects/lord-server/lord
git status
minetest # Вкладка "Начать игру" -> выбрать внизу "lord"

Code-Style

Мы придерживаемся code-style, принятого в Minetest: https://dev.minetest.net/Lua_code_style_guidelines Наши исключения и дополнения:

  • Длина строки до 120 символов
  • Константы капсом
  • Переменные, содержащие описание "класса" с большой буквы, остальные с маленькой
  • Используются одинарные кавычки (в новых файлах и по ходу изменений/рефакторинга)
  • Пустые строки между функциями
    • после require-блока -- 2
    • перед return из модуля/класса (из файла) -- 2
    • между ф-циями/методами -- 1
    • однако, если это ф-ции внутри definition-блока -- 0 (как и между остальными элементами таблицы)

(возможно более актуальный code-style и его обсуждение есть в ветке Discord)

Doc-Blocks

В качестве аннотаций (doc-block'ов) мы используем вариант EmmyDoc.
Подробнее тут: https://emmylua.github.io/annotation.html
Плагин EmmyLua доступен для IntelliJ IDEA, для VSCode и может уже для других IDE: https://github.com/EmmyLua

Установка и настройка LuaCheck:

В качестве линтера и статического анализатора мы используем Luacheck.
Проверки Luacheck запускаются автоматически GitHub'ом на сервисе Travis (см. .travis.yml), но вы можете запускать их локально.

Установка:

  • установите пакетный менеджер LuaRocks:

    sudo apt install luarocks

  • установите LuaCheck:

    luarocks install --local luacheck

    Повторный запуск команды обновит luacheck до последней версии.
    Периодически обновляйте его, т.к. при автоматическом прогоне всегда устанавливается последняя свежая версия.
    Убедитесь, что у вас установлен единственный экземпляр luacheck (например, вы могли ранее установить "глобально" — без флага --local или установить пакет из репозиториев вашего дистрибутива).
    Также убедитесь, что именно этот экземпляр вы используете при прогонах локально.

  • пропишите путь к бинарнику в переменной окружения $PATH:
    например, можно добавить в .bashrc такие строки:

    if [ -d "$HOME/.luarocks/bin" ] ; then
    PATH="$HOME/.luarocks/bin:$PATH"
fi

Проверка:

Прежде чем закоммитить и отправить pull request:

  • запуск проверки в папке с проектом: 
    luacheck .

Обновление своего форка:

  • Добавьте дополнительный remote на оригинальный репозиторий:
    • для начала проверьте, нет ли его уже: 
      $ git remote -v
      должно вывести что-то вроде этого: 
      origin  git@github.com:<your_account>/lord.git (fetch)
origin  git@github.com:<your_account>/lord.git (push)
upstream        git@github.com:lord-server/lord.git (fetch)
upstream        git@github.com:lord-server/lord.git (push)
    • если нет, добавляем новый remote на оригинальный репозиторий: 
      $ git remote add upstream git@github.com:lord-server/lord.git
      проверьте, что получилось: git remote -v
  • Теперь, когда нужно для своего форка обновить, например, ветку dev:
    • не забываем переключиться на эту ветку: git checkout dev
    • стягиваем её с upstream локально: git pull upstream dev --tags --recurse-submodules
    • обновляем в своём форке на GitHub: git push (или git push origin dev)

Релизный процесс:

Два типа релизов:

  • основной (новые фичи, наработки); tag: 2022.03
  • хот-фиксовый патч; tag: 2022.03.p1

Процесс:

  • основной релиз собирается на ветке dev, т.е.:

    • ветка dev теперь является default'ной
    • все PR по умолчанию создаются в эту ветку
    • нужно ветвиться от dev (хотя можно и от master'а)
    • поддерживать в актуальном состоянии ветку dev
    • авто-деплой на Полигон идёт с ветки dev при любых изменениях в этой ветке
    • ветка dev автоматически обновляется из ветки master после релиза (любого -- основного или хотфиксового)
    • когда основной релиз готов (протестирован, готовы катить):
      • ветка dev мерджится в ветку master
      • добавляется bump-commit с changelog'ом (уже на ветке master)
      • ставится tag вида YYYY.MM (напр. 2022.03)
      • авто-деплой:
        • выкатывает это на боевой (с мастера)
        • мерджит master в dev (за счёт мерджа запускается перевыкатка на Полигон)

  • хотфиксовый релиз "собирается" на ветке master, т.е.:

    • ветка master отражает состояние сервера (практически всегда)
    • PR по баг-фиксам принимаются в ветку master
      • если при открытии PR забыли поменять с дефолтной ветки dev на ветку master -- не страшно, можно поменять позже или поменяет reviewer
    • деплой на боевой идёт с ветки master по тегу:
      • добавляется bump-commit с changelog'ом патча
      • ставится патч-tag вида YYYY.MM.pN (2022.03.p1)
      • авто-деплой:
        • выкатывает это на боевой
        • мерджит master в dev (за счёт мерджа запускается выкатка на Полигон)

Изменение конфигов:

Для разработчиков:

Если для вашей задаче требуется внести изменения в конфиг minetest.conf, не забудьте добавить соответствующие изменения в оба файла:

  • в ./minetest.conf.test -- для тестового сервера (Полигона)
  • в ./minetest.conf.prod -- для боевого сервера

Ваши изменения конфигов (после аппрува и мерджа) будут автоматически применены при деплое на соответствующий сервер.

Для DevOps-ов:

Все изменения конфигов на серверах очень предпочтительно делать через реп (как описано выше для разработчиков). Иначе они будут перезаписаны при деплое.
Если всё-таки возникла ситуация, что нужно поменять конфиг на боевом прямо сейчас, не забываем внести изменения в соответствующий файл (./minetest.conf.prod) и закоммитить их. Просьба учесть, что на боевом развёрнута ветка master, но основная ветка dev, а также учесть Релизный процесс

Дополнительные пакеты:

  • python3
  • утилита dot, входит в graphviz
  • питон-модуль поддержки graphviz python3 -m pip install graphviz