Development Workflow

This tutorial walks you through the recommended workflow for developing Odoo on Skysize: write code locally, validate it on a staging environment, then release to production.

Time to complete: ~20 minutes (setup), then ongoing

What you need:

• A production branch already deployed (Deploy Your First Instance)
• A paid or trial plan (staging environments require a subscription)

---

Overview

Skysize supports three branch types that map directly to the three phases of a development workflow:

Branch type	Purpose	Database	Auto-deleted?
Production	Live environment, real users	Persistent	Never
Staging	Pre-release testing, mirrors production	Persistent	Never
Development	Rapid iteration, throwaway testing	Ephemeral	After 24h

The recommended flow is:

local machine → development branch → staging branch → production branch

---

Step 1 — Set up your local development environment

Before touching Skysize, make sure you can run Odoo locally. This is where you write and initially test your changes.

1. Clone your repository:

   git clone [email protected]:your-org/your-odoo-repo.git
   cd your-odoo-repo

2. Create a feature branch:

   git checkout -b feature/my-new-feature

3. Run Odoo locally against a local database. Refer to the Odoo documentation for setup instructions specific to your version.

4. Develop and test your changes locally until you are satisfied.

---

Step 2 — Create a development branch on Skysize

Development branches on Skysize are lightweight, short-lived environments. They spin up on demand and are automatically cleaned up after 24 hours of inactivity, so you can create as many as you need without worrying about cost.

1. Push your feature branch to your repository:

   git push origin feature/my-new-feature

2. In Skysize, go to your project and open the Branches tab.

3. Find feature/my-new-feature in the branch list.

4. Click on it and set the branch type to Development.

5. Set the On Push action to Create New.

   • This deploys a fresh Odoo instance with an empty database every time you push.
   • Use this for testing isolated features that do not depend on existing data.

6. Click Save, then Deploy (or simply push a new commit).

7. Once the build succeeds, open the instance and verify your feature works as expected.

note

Development environments use demo data by default and do not share data with your production database. They are meant for code-level validation, not for testing with real data.

---

Step 3 — Validate on staging

Once your feature works in development, promote it to staging to test it against a realistic copy of your production data.

Create a staging branch

1. Merge (or cherry-pick) your feature branch into a dedicated staging branch. Many teams use a branch called staging or pre-production:

   git checkout staging
   git merge feature/my-new-feature
   git push origin staging

2. In Skysize, open the Branches tab and find the staging branch.

3. Set the branch type to Staging.

4. Set the On Push action to Update.

   • This updates the running instance's code on every push while preserving the database.
   • Your staging environment keeps its data between deployments, so you can test workflows end-to-end.

5. Click Save.

Rebuild staging from production (optional but recommended)

To make staging mirror your current production data:

1. On the staging branch, click Rebuild.
2. Skysize will take a snapshot of your production database and restore it into the staging environment.
3. Wait for the rebuild to complete, then verify your feature against real data.

caution

Rebuilding staging replaces its database with a copy of production. Any data entered directly in the staging environment will be lost.

---

Step 4 — Release to production

Once staging is validated, deploy to production.

1. Merge your changes into your production branch:

   git checkout main
   git merge staging
   git push origin main

2. In Skysize, open the Branches tab and find your production branch.

3. Check the On Push action:

   • Update — the deployment triggers automatically on push. Good for teams that ship frequently and want zero manual steps.

4. Monitor the build status. When it shows Success, your changes are live. If the update fails, a rollback will happen to make sure not data is lost.

note

Skysize updates all custom modules on Update deployments, which upgrades all currently installed modules. If you added a new module to your codebase, it will not be installed automatically — you still need to install it from the Odoo Apps menu after the deployment.

---

Recommended branch setup summary

Branch	Type	On Push	Notes
main	Production	Update	Auto-update
staging	Staging	Update	Auto-update, rebuild from prod as needed
feature/*	Development	Create New	Ephemeral, one per feature

---

Tips

• Keep staging in sync: Rebuild staging from production regularly so your tests reflect real conditions.
• Use development branches liberally: They are free to create and auto-delete, so create one per feature or bug fix.
• Protect your production branch: On GitHub/GitLab, require pull request reviews before merging to main to prevent accidental pushes.
• Monitor deployments: Check the deployment logs in the Skysize dashboard if a build fails. Most failures are caused by a missing Python dependency or a module XML error.