Flujo de desarrollo

Este tutorial te guía por el flujo de trabajo recomendado para desarrollar Odoo en Skysize: escribe el código en local, valídalo en un entorno de staging y luego publícalo en producción.

Tiempo para completarlo: ~20 minutos (configuración), luego de forma continua

Lo que necesitas:

• Una rama de producción ya desplegada (Despliega tu primera instancia)
• Un plan de pago o de prueba (los entornos de staging requieren una suscripción)

---

Descripción general

Skysize admite tres tipos de rama que se corresponden directamente con las tres fases de un flujo de desarrollo:

Tipo de rama	Propósito	Base de datos	¿Se elimina?
Producción	Entorno en vivo, usuarios reales	Persistente	Nunca
Staging	Pruebas previas a la publicación con datos similares a producción	Persistente	Nunca
Desarrollo	Iteración rápida, pruebas desechables	Efímera	Sí, consulta la nota más abajo

El flujo recomendado es:

local machine → development branch → staging branch → production branch

atención

Los despliegues de development se eliminan automáticamente aproximadamente 24 horas después del build: el contenedor se elimina y la base de datos se descarta. Esto mantiene gratuitos los entornos de funcionalidades de corta duración. Si más tarde vuelves a hacer push a una rama de development, Skysize simplemente construye un despliegue nuevo y vacío, tu base de datos anterior no se recupera. Nunca guardes datos que te importen únicamente en un entorno de development.

---

Paso 1: Configura tu entorno de desarrollo local

Antes de tocar Skysize, asegúrate de que puedes ejecutar Odoo en local. Aquí es donde escribes y pruebas inicialmente tus cambios.

1. Clona tu repositorio:

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

2. Crea una rama de funcionalidad:

   git checkout -b feature/my-new-feature

3. Ejecuta Odoo en local contra una base de datos local. Consulta la documentación de Odoo para conocer las instrucciones de configuración específicas de tu versión.

4. Desarrolla y prueba tus cambios en local hasta que estés satisfecho.

---

Paso 2: Crea una rama de development en Skysize

Las ramas de development en Skysize son entornos ligeros y de corta duración. Se activan bajo demanda y se eliminan automáticamente tras 24 horas de inactividad, así que puedes crear tantas como necesites sin preocuparte por el coste.

1. Haz push de tu rama de funcionalidad a tu repositorio:

   git push origin feature/my-new-feature

2. En Skysize, ve a tu proyecto y abre la pestaña Ramas.

3. Busca feature/my-new-feature en la lista de ramas.

4. Haz clic en ella y establece el tipo de rama en Desarrollo.

5. Establece la Acción al actualizar código en Nuevo build.

   • Esto despliega una instancia de Odoo nueva con una base de datos limpia cada vez que haces push.
   • Úsalo para probar funcionalidades aisladas que no dependen de datos existentes.

6. Haz clic en Guardar, luego haz push de un nuevo commit (o haz clic en Reconstruir para desplegar el commit actual de inmediato).

7. Una vez que el build tenga éxito, abre la instancia y verifica que tu funcionalidad funcione como esperas.

nota

Los entornos de development usan datos de demostración de forma predeterminada y no comparten datos con tu base de datos de producción. Están pensados para la validación a nivel de código, no para pruebas con datos reales.

---

Paso 3: Valida en staging

Una vez que tu funcionalidad funcione en development, promuévela a staging para probarla contra una copia realista de tus datos de producción.

Crea una rama de staging

1. Fusiona (o haz cherry-pick de) tu rama de funcionalidad en una rama de staging dedicada. Muchos equipos usan una rama llamada staging o pre-production:

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

2. En Skysize, abre la pestaña Ramas y busca la rama staging.

3. Haz clic en la rama para abrir su configuración y establece el Tipo de rama en Staging. Haz clic en Guardar.

4. Establece la Acción al actualizar código en Actualizar build.

   • Esto actualiza el código de la instancia en ejecución en cada push mientras conserva la base de datos.
   • Tu entorno de staging mantiene sus datos entre despliegues, así que puedes probar flujos de trabajo de principio a fin.

5. Haz clic en Guardar, luego haz push de un commit (o haz clic en Reconstruir) para desplegar staging por primera vez.

Carga staging con datos de producción (opcional pero recomendado)

Para probar tu funcionalidad contra una copia realista de tus datos de producción, restaura una copia de seguridad de producción en la rama de staging:

1. Abre la pestaña Copias de seguridad.
2. Busca una copia de seguridad reciente de tu rama de production (o haz clic primero en Crear copia de seguridad en production para crear una nueva).
3. Haz clic en Restaurar en esa copia de seguridad.
4. En el cuadro de diálogo de restauración, elige tu rama de staging como destino y luego confirma.
5. Espera a que el trabajo de restauración termine y luego verifica tu funcionalidad contra datos reales.

atención

La restauración reemplaza la base de datos de la rama de destino con el contenido de la copia de seguridad. Cualquier dato introducido directamente en el entorno de staging se perderá. El cuadro de diálogo de restauración te avisa si seleccionas accidentalmente tu rama de production como destino, nunca restaures una copia de seguridad de staging sobre production.

sugerencia

Las copias de seguridad son también la forma de mover datos entre entornos en general, puedes restaurar la copia de seguridad de cualquier rama en cualquier otra rama del mismo proyecto.

---

Paso 4: Publica en producción

Una vez validado el staging, despliega en producción.

1. Fusiona tus cambios en tu rama de producción:

   git checkout main
   git merge staging
   git push origin main

2. En Skysize, abre la pestaña Ramas y haz clic en tu rama de producción.

3. Comprueba el ajuste Acción al actualizar código:

   • Actualizar build: el despliegue se activa automáticamente en cada push. Es el valor predeterminado para la rama de producción y es ideal para equipos que publican con frecuencia y quieren cero pasos manuales.
   • No hacer nada: elige esta opción si prefieres controlar exactamente cuándo se actualiza producción, luego despliega manualmente con Reconstruir.

4. Monitorea el estado del despliegue. Cuando muestre En ejecución (estado del build Éxito), tus cambios estarán en vivo. Si una actualización falla, Skysize revierte automáticamente al despliegue funcional anterior, así que no se pierden datos.

nota

En un despliegue de Actualizar build, Skysize actualiza los módulos personalizados que ya están instalados en la base de datos. Un módulo que acabas de añadir a tu código no se instala automáticamente, tras el despliegue, instálalo una vez desde el menú Apps de Odoo. A partir de entonces se actualiza con cada actualización.

---

Resumen de la configuración de ramas recomendada

Rama	Tipo	Acción al actualizar código	Notas
main	Producción	Actualizar build	Actualización automática en cada push
staging	Staging	Actualizar build	Actualización automática; carga datos restaurando una copia de seguridad de producción según sea necesario
feature/*	Desarrollo	Nuevo build	Efímera, una por funcionalidad

---

Consejos

• Mantén staging sincronizado: restaura una copia de seguridad reciente de producción en staging con regularidad para que tus pruebas reflejen condiciones reales.
• Usa las ramas de development con generosidad: son ligeras y se eliminan automáticamente tras unas 24 horas, así que crea una por funcionalidad o corrección de errores y deja que expire.
• Protege tu rama de producción: en GitHub/GitLab, exige revisiones de pull request antes de fusionar en main para evitar pushes accidentales.
• Monitorea los despliegues: revisa los logs del build (abre el despliegue y haz clic en Ver logs) en el panel de Skysize si un despliegue falla. La mayoría de los fallos se deben a una dependencia de Python faltante o a un error en el XML o el manifiesto de un módulo.