Odoo GitHub Deployment

Deploying Odoo from GitHub has become the standard workflow for professional Odoo development. Instead of manually uploading files via FTP or SSH, you push code to a Git repository and the hosting platform automatically builds and deploys your application. This guide explains how Git-based deployment works, best practices for branching, and how to integrate CI/CD into your workflow.

How Git Deployment Works

Git-based Odoo deployment follows a simple workflow. You maintain your Odoo source code, custom modules, and configuration files in a Git repository hosted on GitHub, GitLab, or Bitbucket. When you push changes to the repository, the hosting platform detects the update and triggers an automated build process.

The build process typically involves pulling the latest code, installing Python dependencies, running any build scripts, and restarting the Odoo service. Once the build completes, your changes are live. This eliminates manual deployment steps and reduces the risk of human error.

Most modern Odoo hosting platforms support this workflow natively. You connect your repository, and the platform handles the rest. The key difference between platforms is how they handle build errors, rollbacks, and environment configuration.

Repository Structure for Odoo

A well-organized Odoo repository makes deployment smoother. The typical structure looks like this:

my-odoo-project/
├── odoo/                  # Odoo source (submodule or fork)
├── custom-addons/         # Your custom modules
├── config/
│   ├── odoo.conf          # Odoo configuration
│   └── nginx.conf         # Reverse proxy config
├── requirements.txt       # Python dependencies
├── Dockerfile             # If using Docker
└── docker-compose.yml     # Multi-container setup

Keeping custom modules in a dedicated directory separate from the Odoo source makes upgrades easier. When a new Odoo version is released, you can update the Odoo source without touching your custom code.

Branching Strategy

A clear branching strategy is essential for maintaining stability while enabling active development. Here is a proven approach for Odoo projects:

main / production

This branch contains the code running in production. It should always be stable and deployable. Only thoroughly tested changes are merged into this branch. Direct pushes to production are blocked in most hosting platforms to prevent accidental deployments.

develop / staging

This branch is deployed to a staging environment where changes are tested in a production-like setting. Feature branches are merged here first, tested thoroughly, and then merged to production when ready.

feature/* branches

Individual features or bug fixes are developed in isolated branches. Each branch can be deployed to its own staging environment for review and testing. When approved, the branch is merged into develop and eventually into production.

This workflow ensures that production is always stable, staging catches issues before they reach users, and developers can work independently without stepping on each other's changes.

Staging Environments

Staging environments are one of the biggest benefits of Git-based deployment. A staging environment is a mirror of your production setup where you can test changes before they affect real users. Key uses for staging include:

  • ✓Testing new custom modules before deploying to production
  • ✓Verifying Odoo version upgrades do not break existing functionality
  • ✓Training users on new features without affecting the production system
  • ✓Performance testing with realistic data volumes
  • ✓Client demonstrations using current development progress

The best hosting platforms create staging environments automatically from branches. When you push to a feature branch, a staging environment spins up with the latest code and a copy of the production database. When the branch is deleted, the staging environment is torn down.

CI/CD Integration

Continuous Integration and Continuous Deployment (CI/CD) takes Git-based deployment further by automating quality checks and deployment decisions. A typical Odoo CI/CD pipeline includes:

1.

Code Quality Checks

Run linting, code formatting, and static analysis on every push. This catches style issues and potential bugs before they are merged.

2.

Automated Tests

Run Odoo unit tests and integration tests automatically. If any test fails, the deployment is blocked and the team is notified.

3.

Build and Deploy to Staging

If all checks pass, build the application and deploy to a staging environment for manual review and testing.

4.

Production Deployment

After staging approval, merge to the production branch to trigger a production deployment. Some teams add a manual approval step before production releases.

Tools like GitHub Actions, GitLab CI, and Jenkins make it straightforward to set up these pipelines. For Odoo-specific CI/CD guidance, see our Odoo CI/CD guide.

Best Practices for Odoo Git Deployment

  • →Never commit secrets: Database passwords, API keys, and SSH keys should never be in your repository. Use environment variables instead.
  • →Use meaningful commit messages: Write clear commit messages that explain what changed and why. This helps when reviewing deployment history.
  • →Keep commits small: Smaller, focused commits are easier to review, test, and roll back if needed.
  • →Tag releases: Use Git tags to mark production releases. This makes it easy to identify exactly which code is running in production.
  • →Maintain a changelog: Document changes in a changelog file or release notes. This helps the team and clients understand what changed between versions.

To explore hosting platforms that support these workflows, visit our Odoo GitHub integration page or learn more about Odoo deployment options.