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	Cleaned up?
Production	Live environment, real users	Persistent	Never
Staging	Pre-release testing against production-like data	Persistent	Never
Development	Rapid iteration, throwaway testing	Ephemeral	Yes, see note below

The recommended flow is:

local machine → development branch → staging branch → production branch

caution

Development deployments are automatically cleaned up roughly 24 hours after the build: the container is removed and the database is dropped. This keeps short-lived feature environments free. If you push to a development branch again later, Skysize simply builds a fresh, empty deployment, your earlier database is not recovered. Never keep data you care about only in a development environment.

---

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 Action on Code Update to New Build.

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

6. Click Save, then push a new commit (or click Rebuild to deploy the current commit immediately).

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. Click the branch to open its settings and set the Branch Type to Staging. Click Save.

4. Set Action on Code Update to Update Build.

   • 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, then push a commit (or click Rebuild) to deploy staging for the first time.

Seed staging with production data (optional but recommended)

To test your feature against a realistic copy of your production data, restore a production backup into the staging branch:

1. Open the Backups tab.
2. Find a recent backup of your production branch (or click Backup now on production first to create a fresh one).
3. Click Restore on that backup.
4. In the restore dialog, choose your staging branch as the target, then confirm.
5. Wait for the restore job to finish, then verify your feature against real data.

caution

Restoring replaces the target branch's database with the contents of the backup. Any data entered directly in the staging environment will be lost. The restore dialog warns you if you accidentally select your production branch as the target, never restore a staging backup over production.

tip

Backups are also how you move data between environments in general, you can restore any branch's backup into any other branch of the same project.

---

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 click your production branch.

3. Check the Action on Code Update setting:

   • Update Build: the deployment triggers automatically on every push. This is the default for the production branch and is ideal for teams that ship frequently and want zero manual steps.
   • Do nothing: choose this if you prefer to control exactly when production updates, then deploy manually with Rebuild.

4. Monitor the deployment status. When it shows running (build status Success), your changes are live. If an update fails, Skysize automatically rolls back to the previous working deployment, so no data is lost.

note

On an Update Build deployment, Skysize upgrades the custom modules that are already installed in the database. A module you newly added to your codebase is not installed automatically, after the deployment, install it once from the Odoo Apps menu. From then on it is upgraded with every update.

---

Recommended branch setup summary

Branch	Type	Action on Code Update	Notes
main	Production	Update Build	Auto-update on every push
staging	Staging	Update Build	Auto-update; seed with a production backup restore as needed
feature/*	Development	New Build	Ephemeral, one per feature

---

Tips

• Keep staging in sync: Restore a recent production backup into staging regularly so your tests reflect real conditions.
• Use development branches liberally: They are lightweight and auto-clean after about 24 hours, so create one per feature or bug fix and let it expire.
• Protect your production branch: On GitHub/GitLab, require pull request reviews before merging to main to prevent accidental pushes.
• Monitor deployments: Check the build logs (open the deployment and click View Logs) in the Skysize dashboard if a deployment fails. Most failures are caused by a missing Python dependency or an error in a module's XML or manifest.