Зачем odpm: какие проблемы решает утилита¶
Статья для всех ролей — разработчик, координатор команды, DevOps, новичок. Краткая инструкция для тех, кто запускает впервые и установка на хост — в дружелюбности к новичкам. Масштабирование команды и сценарии — в scaling, team-coordinator.
Для кого этот текст¶
| Роль | Зачем читать |
|---|---|
| Разработчик | Понять, почему «Odoo уже стоит» ≠ готовое рабочее место |
| Координатор / тимлид | Обосновать единый odpm.json и lock в git |
| DevOps / CI | Связать developer/server/ci без трёх разных скриптов |
| Новичок в Odoo | Увидеть полную картину до первого проекта |
Основная цель¶
Сформировал
odpm.jsonв репозитории → коллега клонировал проект → тот же Odoo-стек с аддонами, Python, БД и отладчиком — на ноутбуке, на сервере и в CI.
odpm — не «ещё один способ поставить Odoo», а менеджер воспроизводимого окружения из декларативного manifest (odpm.json), который является частью проекта.
Проблемы по слоям¶
1. «Odoo работает» ≠ «можно разрабатывать»¶
Системный пакет, голый docker run odoo:20 или длинная wiki-инструкция дают запущенный сервис — но это не то же самое, что рабочее место разработчика. Для его создания нужно ответить на вопросы:
- где лежит ваш код и как он попадает в
addons_path; - где исходники ядра для чтения, отладки и LSP;
- где OCA и корпоративные репозитории и какие у них ветки;
- какой Python/venv и какие pip-зависимости у проекта;
- какой odoo.conf связывает всё это вместе.
Без odpm — это либо ручная «склейка» либо целый букет инструментов при каждой смене версии Odoo, компьютера или проекта. С odpm — весь контур доступен в одном каталоге проекта и настраивается из единого описания стека.
2. Multi-repo и пути — «модуль не найден»¶
Зрелый Odoo-проект — не один git-репозиторий, а platform + developing + N зависимостей. Типичные боли:
- забытый каталог в
addons_path; - разные пути на хосте и в контейнере;
- симлинки, subprojects, OCA
oca_dependencies.txt; - «у меня работает» из-за локального расположения каталога с модулями или платформы.
Если используетет odpm — то вы получаете централизованный механизм согласования, map_folders, nested odpm.json, deps.lock.json, возможность подстановки ${VAR} в manifest для локальных путей без форка json в git.
3. Разнородные ОС и архитектуры в распределённой команде¶
Без odpm / с инструкциями «под свою машину»:
- отдельные гайды: Ubuntu, Fedora, macOS, Windows (WSL), Apple Silicon;
- пути (
/home/...vsC:\vs/Users/...), shell, права, line endings; - Python/pip и нативные wheels под конкретную архитектуру хоста;
- «у меня на Linux на x86 работает» — у коллеги на macOS на ARM и там ошибка;
- CI происходит на amd64, а ноутбук разработчика на arm64 — сюрпризы при сборке образа или бинарных зависимостей;
- onboarding = «сначала выясни ОС, потом открой нужную ветку wiki».
С odpm:
- один
odpm.jsonв git — один состав стека для всей команды; - локальные отличия машины — в
.env, а не очередная портянка wiki; - поле
archв manifest и lock venv учитывают архитектуру; CI-образ формируется под целевую платформу; - все сводится к инструкации установки самого odpm на Linux / macOS / WSL — без отдельного описания «как поднять Odoo» на каждую ОС.
Честная граница: arm64 на Mac и amd64 на CI не разрешаются сами; для Apple Silicon могут понадобиться multi-arch образы или builder той же архитектуры. Правила (manifest, compose, lock, сценарии) у команды остаются одними — подробнее в масштабировании.
Типичный ответ на эту боль — Docker (следующий пункт): единый runtime внутри контейнера. Но без оркестратора контейнер сам по себе проблему не закрывает.
4. Docker удваивает сложность, если нет оркестратора¶
Чтобы снять боль из п. 3, команды идут в Docker — контейнеры дают одинаковость Ubuntu/macOS/Windows внутри образа. Но без оркестратора Docker переносит сложность на другой уровень:
- связываение путей на локальной машине и внутри контейнера;
- UID/GID и права на файлы;
- compose + PostgreSQL + порты;
- pip-пакеты надо ставить внутрь контейнера;
- отладчик должен иметь доступ к процессу внутри контейнера.
С odpm (оркестратор поверх Docker):
- на хосте — Docker, git и odpm; один сценарий запуска на любой настольной ОС;
- стек Odoo (Debian-образ, Python, venv, postgres, compose) в контейнере по одному
odpm.json; - автоматическая генерация docker-compose.yml, Dockerfile, odoo.conf, volume mapping, настройка отладчиков и остального «docker-слоя».
5. «У каждого своё» — боль команды¶
Без общего manifest:
- у одного Python 3.10, у другого 3.12;
- разные состояния зависимостей OCA;
- разные способы поднять postgres/debugger;
- onboarding = длинный чеклист на десятки пунктов.
C odpm — разделение командного (odpm.json + lock в git) и личного (user_settings.json, .env на машине). Координатор фиксирует стек; остальные воспроизводят задекларированное. См. разделение конфигурации.
6. Три роли — один движок¶
Одна кодовая база, разное поведение по ODPM_SCENARIO:
| Роль | Боль без odpm | Что даёт odpm |
|---|---|---|
| Разработчик | долгая настройка под свой компьютер | developer: полный арсенал разработки, дебаггер, CLI, VS Code и PyCharm |
| Сервер / VM | отдельная настройка проекта | server: тот же стек, без dev-утилит, postgres на localhost |
| CI | отдельные сценарии сборки | ci: baked-образ по тем же правилам, что и у команды |
Один pipeline, профиль задаёт сценарий.
7. Непредсказуемость при повторной настройке¶
Без odpm (свои скрипты, ansible, «setup.sh», ручной compose):
- неясно, что править руками, а что перегенерируется;
- повторный setup затирает
docker-compose.yml, Dockerfile или конфиг; - нет dry-run — последствия видны после факта запуска;
- нет общего списка «generated vs source of truth».
C odpm:
odpm plan— позволяет увидеть набор шагов и diff до запуска всей системы;- перечень сгенерированных файлов;
- для генерации атрефактов(compose, runtime config) применяются шаблоны, которые лежат в каталоге
.odpm/; - один manifest описывает состав стека.
8. Операционные задачи размазаны по инструментам¶
Помимо «поднять Odoo», в работе нужны:
- restore БД из архива;
- новая БД с языком/страной/demo;
- сброс пароля admin;
- установка и обновление модулей (
-i/-u); - pre-commit в контейнере;
- секреты модулей без коммита в git.
С odpm — единый CLI-оркестратор вокруг одного compose-стека (справочник CLI, секреты).
9. IDE и отладка¶
Без odpm: вручную надо настроить launch.json опеспечив path mappings host/container, или настроит extraPaths для Pylance, совместимость PyCharm/pydevd.
С odpm: debug-profile.json, автоматическая генерация VSCode/PyCharm конфигов, автоматически устанавливаются debugpy и odoo-stubs в сценарии developer. См. отладку в IDE.
10. CI и воспроизводимость сборок¶
Без odpm:
- на CI другой pip/venv;
- зависимости без зафиксированных SHA;
- образ собирается ad-hoc.
С odpm: deps.lock.json, --update-lock, запекание CI-образа по хэшам коммитов. См. сценарий ci.
Где odpm на карте решений¶
Ниша между «голым Docker Odoo» и тяжёлым Doodba / Odoo.sh. Ниже — сравнение по слоям задач (актуально для линейки 4.7).
Позиция решений¶
| Решение | Что это | Где ниша |
|---|---|---|
| Пакет / bare metal | deb / rpm / exe, systemd | «Odoo запущен», не готовое рабочее место |
| Official Odoo Docker | один образ + PostgreSQL | демо и простой стенд |
| Dev Containers / свой compose | общий Docker-паттерн | нет Odoo-специфики из коробки |
| odpm | manifest + оркестратор поверх Docker | self-hosted: разработчик, сервер, CI из одного odpm.json |
| Doodba | зрелый DevOps-стек вокруг Odoo | мощно, высокий порог, конвенция custom/ |
| Odoo.sh | облачный PaaS | SaaS; не ваш ноутбук и не произвольный VPS |
Матрица функционала¶
Легенда: ● сильная поддержка · ◐ частично / другим способом · ○ нет или не цель продукта.
| Возможность | Пакет | Official Docker | Dev Container | odpm | Doodba | Odoo.sh |
|---|---|---|---|---|---|---|
| Multi-repo (platform + project + deps) | ○ | ○ | ◐ руками | ● | ● | ● |
| Lock ревизий git | ○ | ○ | ◐ | ● deps.lock |
● | ● внутри SaaS |
| Один состав → developer / server / CI | ○ | ○ | ○ | ● сценарии + overlays | ◐ свои профили | ● их пайплайн |
| Генерация compose / Dockerfile / odoo.conf | ○ | ○ | ◐ шаблон | ● + odpm plan |
● | ○ (закрытый контур) |
| Отладка в IDE (VS Code / PyCharm) | ○ | ○ | ◐ | ● | ◐ | ограниченно |
| Операции БД и модулей из CLI | ○ | ○ | ○ | ● | ◐ скрипты / custom |
● UI / CI |
| Sidecar-сервисы | ○ | ○ | ◐ | ● services / service_sources |
● | ◐ |
| Секреты без коммита в git | ○ | ○ | ◐ | ● | ◐ | ● SaaS |
| Плагины / lifecycle hooks | ○ | ○ | ○ | ● | ● custom/ |
○ |
| Self-hosted на своей машине | ● | ● | ● | ● | ● | ○ |
| Staging / prod как PaaS | ○ | ○ | ○ | ○ | ◐ сами | ● |
| Порог входа для новичка | «поставить» легко, «разрабатывать» тяжело | средний | средний+ | низкий–средний | высокий | низкий в облаке |
| Полный prod: nginx / TLS / backup | ◐ | ○ | ○ | ○ | ◐ | ● |
См. также масштабирование команды, плагины, сценарии.
Относительно «лёгких» решений¶
Пакет, official Docker и голый Dev Container обычно дают запущенный сервис, но не закрывают multi-repo, lock, три роли, IDE-отладку и повседневные операции с БД/модулями из одного контракта. odpm как раз собирает этот контур: один odpm.json, предсказуемый plan, контейнерный стек на разных ОС и архитектурах.
Пересечение с Doodba¶
Общий класс задач: multi-repo Odoo в Docker, расширение стека, CI-образ, sidecars.
Другой угол: у odpm контракт — declarative odpm.json и сценарии (developer / server / ci); у Doodba — своя экосистема и богатый набор build/entrypoint в custom/. Цель odpm — не быть drop-in заменой всего surface Doodba custom/ (см. раздел ниже), а снизить порог и держать один воспроизводимый контур для команды.
Пересечение с Odoo.sh¶
Odoo.sh выигрывает там, где нужен managed staging/prod и встроенный облачный CI/CD.
odpm выигрывает на локальной машине, своём сервере, в self-hosted и air-gapped контурах: полный контроль над compose, секретами и одним описанием без привязки к SaaS.
odpm — Odoo-specific Dev Container manager: declarative manifest + scenario + plan + container contract, без облачной привязки.
Что odpm сознательно не решает¶
- Не PaaS — нет staging/prod как у Odoo.sh.
- Не полный prod-hardening —
serverдаёт профиль, nginx/TLS/backup — на вас (безопасность). - Не замена знанию Odoo — framework, ORM, модули нужно учить.
- Plugins/hooks - нет задачи повторить весь объём Doodba
custom/hooks. - Не byte-identical reproducibility (как Nix) — практическая воспроизводимость через lock + image + manifest.
Следующие шаги¶
- Дружелюбность к новичкам — что установить на хост и первый запуск.
- Локальная разработка с нуля —
odpm init, первая база. - Координатор команды — lock, non-interactive, CI.
- Сценарий developer — отладка и
dev_mode.
Кратко¶
Odoo-разработка ломается не на синтаксисе Python, а на инфраструктуре: multi-repo, пути, разные ОС и архитектуры в команде, Docker, venv, конфиг, IDE, CI. odpm превращает это в один воспроизводимый проектный контур из
odpm.json, чтобы команда тратила время на создание модулей, а не на повторную сборку окружения.