在啟動專案時,我的第一個步驟是設計適當的 Git repository 及文件結構,為文件結構和命名方式找到最佳方案,蠻愉悅的XXD。以下是我逐步形成三層結構的思考過程。
首先,我決定每個模組都應該擁有自己的 repository。這個決定基於以下幾個原因:
透過這種方式,每個模組都能被單獨開發、測試和部署,提升了專案的靈活性。
在確立了模組的獨立性之後,我自然地想到需要一個整合的 repository,來統籌管理所有模組,這就是 odooBundle-Codebase。在這個 repo 中,我們將各種模組作為 submodule 引入,odoo 社群版本身也被視為一個 submodule。
這樣的設計帶來了以下優點:
這個整合的 repo 成為系統的核心代碼庫,連結了各個獨立的模組。
最後一定要有的是用於部署的 repository,我命名為 WebApp-Deployment。這個 repo 的主要功能是管理實際環境的部署設定,並且統籌多個 web 應用的運行。
這層的設計考量包括:
透過這個部署層的 repo,我們可以:
經過上述的思考過程,最終形成了這個三層的 Git repository 結構
在設計 Git repository 結構時,最初我打算將 Dockerfile 放在 WebApp-Deployment 這個 repository 裡,因為它負責實際的環境部署,管理各個應用和容器。這樣做的好處是將部署相關的設定集中在一處,便於管理。而且雖然 odooBundle-Codebase 需要管理整合各種模組,但當時希望更精確地鎖定各個 Python 依賴套件的版本。為了達成這個目標,我考慮使用 Poetry 來管理。當時的想法是,如果使用 Poetry 來處理依賴關係,那麼 Dockerfile 就可以相對簡化,並與 odooBundle-Codebase 解耦。
但是,由於某些原因(之後的文章會詳細討論),我在前幾天決定暫時停用 Poetry,並且將依賴套件的控制移動回 Dockerfile。這讓我重新思考 Dockerfile 的放置位置。因為依賴關係是與原始碼密切相關的,將 Dockerfile 放在 odooBundle-Codebase 層級會更為合理。這樣,我們可以在同一個 repository 中管理代碼和依賴,確保整體的一致性。
最終,我決定將 Dockerfile 放在 odooBundle-Codebase 中,並透過 entrypoint.sh 等方式,將開發(dev)和生產(prod)環境所需的資訊以 Docker 參數的形式傳遞進去。這樣一來,我們既能夠保持代碼與依賴的緊密關聯,又能在部署時靈活地調整環境設定。
最後,我想分享一下目前的檔案結構,供大家參考。
odooBundle-codebase/
├── addons # 預計拿來放 submodule
├── check-db-status.py
├── docker-compose.yml # 只是測試用
├── Dockerfile
├── entrypoint.sh
├── odoo # Odoo 社群版的 submodule
│ ├── ...
│ └── odoo-bin
└── tutorials # 教學練習用,也類似 addons 資料夾,被加入 .gitignore
├── awesome_clicker
├── awesome_dashboard
├── awesome_gallery
├── awesome_kanban
├── awesome_owl
├── estate
└── README.md
WebApp-Deployment/
├── config
│ ├── certs
│ ├── dev.env
│ ├── pgadmin.env
│ └── prod.env
├── config.example # 範例配置檔,避免將真實憑證提交到 Git
│ ├── certs
│ ├── dev.env
│ ├── pgadmin.env
│ └── prod.env
├── docker-compose.yml
├── odoo-dev
│ ├── logs
│ ├── odoo.conf
│ └── source # submodule: odooBundle-Codebase 的 dev 分支
├── odoo-prod
│ ├── logs
│ ├── odoo.conf
│ └── source # submodule: odooBundle-Codebase 的 prod 分支
├── postgresql-admin
│ └── servers.json
└── reverse-proxy
├── conf.d
├── html
└── nginx.conf