Масштабирование и единый контур для команды

Контекст «зачем odpm» и боли распределённых команд: Зачем odpm.

Идея

Один инструмент — разработчик, системный администратор и инженер непрерывной интеграции — работают с одним описанием проекта (odpm.json и при необходимости файл фиксации версий .odpm/deps.lock.json). Меняется не «набор разных скриптов и Dockerfile», а только сценарий запуска (ODPM_SCENARIO): разработка на ноутбуке, служба на сервере или готовый образ для конвейера сборки.

Так устраняется типичная боль Odoo-команд: у разработчика «всё работает», на тестовом стенде — другие пути и версии, в автоматической сборке — третий вариант окружения.

Разные компьютеры — один состав внутри контейнера

В команде обычно разные рабочие станции: Linux, Windows (через WSL), macOS; процессоры Intel/AMD и Apple Silicon. Без общего слоя быстро множатся проблемы:

• «на Ubuntu ставится, на macOS — нет» (пути, права, оболочка, зависимости);
• колёса Python и нативные расширения, собранные под одну архитектуру;
• разные версии PostgreSQL и Python «на голом железе»;
• отдельные длинные инструкции под каждую систему.

odpm переносит стек Odoo в контейнер, описанный в odpm.json. На хосте остаются Docker, git и odpm. Разработчик на ноутбуке, администратор на VPS и машина сборки получают одинаковое содержимое внутри контейнера; отличаются только способ подключения исходников (с диска или из образа) и политика безопасности.

На компьютере пользователя (может отличаться)	Внутри контейнера (единое для всех)
Linux, Windows, macOS	Образ на базе Debian из шаблона odpm
Разная архитектура процессора	Зафиксированные версии Python, политика окружения, точка входа
Свои пути к клонам git	Одинаковые правила compose и передачи конфигурации

Полного совпадения «ноутбук на ARM = сервер сборки на x86_64» odpm сам по себе не обеспечивает: для машин Apple Silicon важны многоархитектурные образы или выделенный сервер той же архитектуры. Но правила игры (файл описания, compose, фиксация зависимостей) остаются общими.

Роли и сценарии

Роль	Сценарий	Что получает
Разработчик	developer	Исходники с диска, отладчик, режим разработки Odoo
Системный администратор	server	Тот же состав проекта, без отладчика, усиленная изоляция базы
Инженер сборки	ci	Образ с встроенными исходниками и окружением Python

Команда odpm plan помогает договориться до изменений: все видят один и тот же план шагов подготовки и отличия в генерируемых файлах.

Три сценария — один состав проекта

Меняется упаковка, а не список репозиториев и зафиксированных ревизий:

	developer	server	ci
Исходники Odoo и дополнений	Подключены с диска хоста	Подключены с диска (например VPS)	Встроены в образ при сборке
Окружение Python	Пересоздаётся при изменении фиксации	То же	Собрано заранее в образе
Отладчик	Да	Нет	Нет
Типичное место	Ноутбук	Виртуальная машина / VPS	Машина непрерывной интеграции

Масштаб развёртывания

Небольшой контур (пилот, демо для заказчика, одна виртуальная машина):

• сценарий server (или developer только на машине разработчика);
• один docker compose: Odoo и PostgreSQL;
• HTTPS через nginx или другой обратный прокси.

Средний контур (команда + тестовый стенд + автоматическая проверка):

• разработчики на developer, стенд на server, сборка на ci;
• один odpm.json в общем git-репозитории;
• проверка compose при каждом изменении.

Крупный контур (реестр образов, несколько сред):

odpm --build-image  →  реестр образов  →  развёртывание (ВМ, оркестратор)

odpm — звено сборки воспроизводимого образа Odoo, а не замена GitHub Actions, GitLab CI или систем оркестрации. Описание проекта и фиксация версий хранятся в git.

Что именно унифицируется

Артефакт	Разработчик	Администратор	Сборка
odpm.json / фиксация версий	правит зависимости	читает	проверяет строго
docker-compose.yml	генерирует odpm	то же	то же (в ci без подключения исходников с хоста)
Конфигурация runtime	передаётся в контейнер	то же	встроена в образ

Один репозиторий проекта, один odpm.json, три сценария — разработчик, администратор и сборка сходятся к одному стеку Odoo. Масштаб меняет способ упаковки (compose на виртуальной машине или образ в реестре), а не правила описания проекта.