Ramas

La vista de ramas ofrece un resumen de las diferentes ramas de su repositorio.

Etapas

Odoo.sh ofrece tres etapas diferentes para las ramas:

• Producción

• Etapa de prueba

• Desarrollo

Puede cambiar la etapa de una rama arrastrándola y soltándola bajo la etapa deseada.

Nota

• Las ramas de desarrollo se pueden mover a Etapa de prueba. Si intenta mover una rama de desarrollo a Producción, aparecerá un mensaje de advertencia que explica que solo puede tener una rama de producción por proyecto.

• Las ramas de prueba se pueden mover a Desarrollo, pero no es posible moverlas a Producción.

• La rama de producción solo se puede mover a Desarrollo. Si intenta moverla a Etapa de prueba, solo podrá realizar una fusión. Consulte la sección fusión para obtener una explicación detallada de este proceso.

Producción

La rama de producción contiene el código utilizado para ejecutar la base de datos de producción. Solo puede haber una rama de producción.

Cuando envía un nuevo commit a esta rama, el servidor de producción se actualiza con el código revisado y se reinicia.

Si los cambios requieren una actualización del módulo, como modificar una vista de formulario, y desea que la actualización se realice de forma automática, puede aumentar el número de versión del módulo en su archivo de manifiesto (__manifest__.py). La plataforma realizará entonces la actualización, durante la cual la instancia no estará disponible temporalmente por motivos de mantenimiento.

Este método equivale a actualizar el módulo mediante el menú Aplicaciones o el modificador -u en la línea de comandos.

Nota

• Si los cambios impiden que el servidor se reinicie o si la actualización del módulo falla, el servidor regresa de forma automática a la última revisión de código exitosa y la base de datos se restaura a su estado anterior. Acceda al registro de la actualización fallida para solucionar el problema.

• Los datos de demostración no se cargan, ya que no están destinados a utilizarse en una base de datos de producción. Las pruebas unitarias no se ejecutan, ya que aumentarían el tiempo de indisponibilidad de la base de datos de producción durante la actualización.

Odoo.sh respalda la base de datos de producción de forma automática. Conserva siete respaldos diarios, cuatro semanales y tres mensuales. Cada respaldo incluye el volcado de la base de datos, el filestore (adjuntos y campos binarios), los registros y las sesiones.

Advertencia

Al utilizar proyectos de prueba, la rama de producción y todas las ramas de prueba regresan de forma automática a la etapa de desarrollo después de 30 días.

Etapa de prueba

Las ramas de prueba están diseñadas para probar nuevas funciones utilizando datos de producción sin comprometer la base de datos de producción real con registros de prueba. Estas ramas crean duplicados neutralizados de la base de datos de producción.

La neutralización desactiva lo siguiente:

• Acciones planificadas

  Nota

  Para probarlas, actívelas de forma manual o vuelva a habilitarlas. Tenga en cuenta que la plataforma las activará con menos frecuencia si nadie está utilizando la base de datos, con el fin de ahorrar recursos.

• Correos electrónicos salientes

  Nota

  En su lugar, se interceptan mediante un mailcatcher. Su proyecto de Odoo.sh incluye una interfaz para ver los correos electrónicos enviados por la base de datos. De esta forma, no se envía ningún correo electrónico a sus contactos.

• Servicios de compras dentro de la aplicación (IAP)

• Proveedores de pago y conectores de envío

  Nota

  Se configuran en modo de prueba.

Si configura o visualiza cambios en una base de datos de prueba, asegúrese de registrarlos (anotándolos paso a paso, reproduciéndolos en producción, etc.) o de escribirlos directamente en los módulos de la rama, mediante archivos de datos XML para sobrescribir la configuración o las vistas predeterminadas. Consulte la documentación sobre el primer módulo para ver ejemplos.

Nota

Las pruebas unitarias no se ejecutan, ya que dependen de los datos de demostración, los cuales no se cargan en las bases de datos de producción ni de prueba. Si Odoo empieza a permitir la ejecución de las pruebas sin datos de demostración, Odoo.sh evaluará la posibilidad de ejecutarlas en las bases de datos de prueba.

Las bases de datos de prueba no se respaldan de forma automática. Sin embargo, puede restaurar un respaldo de la base de datos de producción en una rama de prueba con fines de prueba o para recuperar manualmente datos que se hayan eliminado por accidente de la base de datos de producción. Es posible crear respaldos manuales de las bases de datos de prueba.

Desarrollo

Las ramas de desarrollo crean nuevas bases de datos con datos de demostración para ejecutar las pruebas unitarias. Los módulos instalados son los que están incluidos en la rama. Puede cambiar esta lista de módulos a instalar en la configuración del proyecto.

Al enviar un commit a una rama de desarrollo, se inicia un nuevo servidor con una base de datos creada desde cero y se actualiza la rama. Los datos de demostración se cargan y, de forma predeterminada, se ejecutan las pruebas unitarias para comprobar que los cambios no afecten ninguna de las funciones probadas. Puede desactivar las pruebas o permitir que se ejecuten pruebas específicas con etiquetas personalizadas desde la configuración de la rama.

Al igual que con las ramas de prueba, los correos electrónicos no se envían, sino que se interceptan mediante un mailcatcher, y las acciones planificadas no se activan mientras la base de datos no esté en uso.

Las bases de datos de desarrollo no se respaldan de forma automática y no es posible crear respaldos manuales.

Advertencia

Las bases de datos creadas para las ramas de desarrollo están diseñadas para durar aproximadamente tres días. Después de ese periodo, es posible que se eliminen de forma automática para dejar espacio a nuevas bases de datos, sin previo aviso.

Fusionar ramas

Puede fusionar sus ramas arrastrándolas y soltándolas una sobre otra.

Para probar los cambios de las ramas de desarrollo con los datos de producción, puede hacer lo siguiente:

• Fusionar la rama de desarrollo en una rama de prueba arrastrándola y soltándola sobre la rama deseada; o

  

• Arrastre y suelte la rama de desarrollo bajo la sección Etapa de prueba para convertirla en una rama de prueba.

  

Cuando los cambios estén listos para producción, arrastre y suelte la rama de prueba sobre la rama de producción para fusionarlos e implementarlos.

Nota

• Puede fusionar ramas de desarrollo directamente en la rama de producción. Sin embargo, los cambios no se validarán con los datos de producción mediante una rama de prueba, por lo que existe un mayor riesgo de que surjan problemas en la base de datos de producción.

• Puede fusionar ramas de desarrollo entre sí, así como ramas de prueba entre sí.

• También puede utilizar git merge directamente en su equipo de trabajo para fusionar sus ramas. Odoo.sh recibe una notificación cuando se envían nuevas revisiones a sus ramas.

Al fusionar una rama de prueba en la rama de producción, solo se fusiona el código fuente. Los cambios realizados en la base de datos de prueba no se transfieren a la base de datos de producción. Sin embargo, si modifica el código en el repositorio, este se transferirá a la rama de producción al momento de la fusión.

Si prueba cambios de configuración en ramas de prueba y desea que se apliquen a la rama de producción, deberá hacer una de las siguientes acciones:

• Escribir los cambios de configuración en archivos de datos XML para sobrescribir la configuración o las vistas predeterminadas de la rama y, después, aumentar la versión del módulo en su manifiesto (__manifest__.py) para activar la actualización del módulo al fusionar la rama de prueba en la rama de producción.

  Nota

  Se recomienda este método para una mejor escalabilidad de sus desarrollos, ya que utilizará las funciones de control de versiones de Git para todos los cambios de configuración, lo que garantiza la trazabilidad de sus cambios.

• Transferirlos de forma manual de la base de datos de prueba a la de producción, copiándolos y pegándolos.

Etiquetas

Historial

La pestaña Historial ofrece un resumen del historial de la rama:

• Los mensajes de los commits y sus autores

• Los distintos eventos relacionados con la plataforma, como cambios de etapa, importaciones de bases de datos y restauraciones de respaldos

En la esquina superior derecha de cada evento se muestra un estado que indica la operación actual en la base de datos (por ejemplo, instalación, actualización, importación de respaldo) o su resultado (por ejemplo, comentarios de las pruebas, importación de respaldo exitosa). Si una operación se completa con éxito, aparece el botón Conectar, que le permite acceder a la base de datos.

Correos

La pestaña Correos contiene el mailcatcher, que ofrece un resumen de los correos electrónicos enviados por la base de datos.

Nota

El mailcatcher está disponible para las ramas de desarrollo y de prueba. Los correos electrónicos de la base de datos de producción sí se envían y no son interceptados por el mailcatcher.

Shell

La pestaña Shell proporciona acceso shell al contenedor.

Al hacer clic en Shell se abre una nueva pestaña del navegador en la que puede ejecutar comandos básicos de Linux (ls, top). Puede abrir un shell en la base de datos ejecutando psql.

Truco

Puede abrir varias pestañas de shell a la vez y organizar su disposición arrastrándolas y soltándolas.

Nota

• Los shells de las instancias de producción se resaltan en rojo para enfatizar el peligro de manipular directamente las instancias de producción, mientras que los shells de las instancias de prueba o desarrollo se resaltan en amarillo.

• Las instancias de shell de larga duración o las sesiones de shell inactivas se pueden finalizar en cualquier momento para liberar recursos.

Comandos

A continuación encontrará un resumen de comandos útiles que puede ejecutar en la terminal de una base de datos de Odoo.sh:

• odoo-bin shell: para abrir un shell de Odoo

• odoo-update: para actualizar los módulos de la base de datos

• odoosh-restart: para reiniciar los servicios de Odoo.sh (http o cron)

• odoosh-storage: para verificar el uso de almacenamiento del sistema de archivos del contenedor de su instancia

• psql: para abrir un shell de base de datos

• mutt: para verificar cómo se ven los correos electrónicos en clientes de texto (instancias de prueba y desarrollo)

• lnav ~/logs/odoo.log: para navegar por el archivo odoo.log de su instancia

• ncdu: para iniciar el analizador de uso de disco con una interfaz interactiva

• grep: para filtrar y buscar información en archivos de registro o de configuración

Editor

Al hacer clic en Editor se abre una nueva pestaña del navegador para acceder a un entorno de desarrollo integrado (IDE) en línea donde puede editar el código fuente. También puede abrir terminales, consolas de Python y consolas de shell de Odoo.

Puede abrir varias pestañas y arrastrarlas y soltarlas para organizar la disposición como prefiera.

Ver también

Documentación sobre el editor en línea.

Monitor

La pestaña Monitor muestra varias métricas de supervisión del rendimiento de la compilación actual.

Utilice el cursor para hacer zoom y ajustar el rango de tiempo, o selecciónelo manualmente desde el selector de rango de tiempo. También es posible cambiar la zona horaria.

Nota

• Los registros técnicos siempre utilizan el UTC. Para analizar estos registros junto con sus métricas de supervisión, asegúrese de seleccionar UTC en la herramienta de supervisión.

• De igual forma, al enviar un ticket de soporte, asegúrese de que la información que comparte esté basada en UTC, ya que Odoo utiliza esta zona horaria para investigar problemas de rendimiento.

La información se agrega de forma periódica. Cuando esto ocurre, se muestra una línea punteada azul junto con la etiqueta Fecha de agregación. Esto significa que los datos anteriores a esta fecha aparecerán simplificados en comparación con los datos posteriores a ella. Por lo tanto, al utilizar la herramienta de supervisión, se recomienda centrarse en los eventos recientes para obtener la información más detallada posible.

Nota

Las líneas punteadas de otros colores le ayudan a relacionar otros cambios en la compilación (importación de base de datos, git push, etc.).

Truco

En cada gráfico se muestra un ícono 𝕚 (información) en la esquina superior izquierda. Coloque el cursor sobre él para obtener más detalles sobre lo que representa el gráfico.

Métricas

Sistema

El gráfico Memoria muestra información sobre el consumo de memoria:

• Memoria del contenedor representa los workers de Odoo y los procesos del contenedor.

• Memoria de postgresql representa la base de datos.

El gráfico CPU muestra información sobre el consumo de CPU:

• CPU http representa los workers de Odoo.

• CPU cron/mail representa las acciones planificadas y los correos electrónicos entrantes.

• CPU postgresql (procesos de la base de datos)

• CPU other representa los webshells, el editor, etc.

El gráfico Almacenamiento muestra información sobre el almacenamiento utilizado:

• Contenedor representa el filestore, los archivos de registro y los archivos de usuario.

• Postgresql representa la base de datos y los índices.

HTTP

El gráfico Solicitudes muestra información sobre el número de solicitudes HTTP por segundo:

• HTTP successes representa las solicitudes exitosas.

• HTTP errors representa las solicitudes fallidas (consulte odoo.log).

• HTTP rate limited representa las solicitudes rechazadas, posiblemente debido a la falta de workers.

El gráfico Concurrent requests (max) muestra el número máximo de solicitudes HTTP simultáneas por segundo.

Nota

Los workers de la base de datos determinan el número de solicitudes simultáneas que se pueden gestionar a la vez. Es fundamental contar con suficientes workers para atender todas las solicitudes entrantes a medida que llegan. Sin embargo, contar con workers adicionales más allá de este número no mejora la velocidad de procesamiento de las solicitudes.

El Average Response time muestra el tiempo de respuesta promedio a las solicitudes HTTP (en milisegundos).

Correos

El gráfico Incoming muestra datos sobre el número diario de correos electrónicos entrantes:

• Received Emails representa los correos electrónicos que se recibieron con éxito.

• Received Emails bounced representa los correos electrónicos que no se recibieron con éxito.

El gráfico Outgoing muestra datos sobre el número diario de correos electrónicos salientes:

• Sent Emails representa los correos electrónicos que se enviaron con éxito.

• Sent Emails bounced representa los correos electrónicos que no se enviaron con éxito.

Registros

La pestaña Logs ofrece una vista en tiempo real de los registros de su servidor.

Hay distintos registros disponibles:

• pip.log: la instalación de las dependencias de Python

• install.log: the database installation (for development branches, tests are included)

• odoosh-import-database.log: the last imported dump process

• odoo.log: the running server

• update.log: the database updates

• pg_slow_queries.log: psql queries that take an unusual amount of time

• sh_webshell.log: the actions taken in the webshell

• sh_editor.log: the actions taken in the editor

• neutralize.log: the neutralization of the database (only staging)

When new lines are added to the logs, they are displayed automatically. If you scroll to the bottom, the browser scrolls automatically each time a new line is added.

You can pause the logs fetching process by clicking the (pause) button in the upper right corner. Otherwise, the process stops after five minutes. You can restart it by clicking the (play) button.

Respaldos

The Backups tab lists the available backups to download and restore, lets you perform a manual backup and import a database.

The production database is automatically backed up daily. Seven daily, four weekly, and three monthly backups are kept. Each backup includes the database dump, the filestore (attachments and binary fields), logs, and sessions.

Nota

You can refer to the estimated scheduling of automatic backups to gain a better understanding of how the system works. This file is updated daily, taking the current day as the departure point.

Staging and development databases are not automatically backed up. However, you can restore a backup of the production database in your staging branches, for testing purposes, or manually recover data that has been accidentally deleted from the production database.

The list contains the backups kept on the server of your production database. This server only keeps one month of backups: seven daily and four weekly backups.

Dedicated backup servers keep the same backups, as well as three additional monthly backups. To restore or download one of these monthly backups, contact Odoo Support.

When merging a commit updating the version of one or several modules (in __manifest__.py), or their linked Python dependencies (in requirements.txt), then Odoo.sh performs an automatic backup (flagged with type Update in the list), as either the container will be changed by the installation of new pip packages, either the database itself will be changed with the module update triggered afterwards. In these two cases, a backup is triggered as it may break something.

If the merged commit does not update the version of a module or linked dependencies, then no backup is triggered by Odoo.sh, as neither the container nor the database is modified; therefore, the platform considers this safe enough. As an extra precaution, you can make a manual backup before modifiyng production sources.

The purpose of manual backups is to create a specific snapshot of production or staging databases (not available for development). These remain available for seven days. However, there is a limit of five daily manual backups.

Stage	Automatic backup	Manual backup
Producción	Yes (up to 3 months)	Yes (3 days)
Etapa de prueba	No	Yes (3 days)
Desarrollo	No	No

The Import Database feature accepts database archives from:

• the standard Odoo database manager (available for on-premise Odoo servers under /web/database/manager)

• the Odoo Online databases manager

• the Odoo.sh Backups tab (using the (Download Options) button)

• the Odoo.sh Builds view (by clicking Download DB dump)

Actualizar

The Upgrade tab can be used to upgrade production and staging branches of valid projects. For more information about the upgrade process, refer to the Upgrade documentation.

Tools

The Tools tab contains the code profiler. It is used to start a profiling session, recording the activities of Odoo workers running in the instance for a maximum of five minutes. You can choose to terminate the session earlier, as running the tool for a shorter duration reduces the amount of noise in the report.

After each session, an interactive flame graph is created to help you visualize how the Odoo workers allocate their time.

Advertencia

Running the profiler consumes a lot of server resources, so avoid letting it run for too long. The goal is to record a specific action in your database.

Ajustes

The Settings tab lists the configuration options available for the currently selected branch. The options vary for each stage.

Behavior upon new commits

You can change the branch’s behavior upon receiving a new commit for development and staging branches.

By default, a development branch creates a new build and a staging branch updates the previous build. This is useful if the feature you are working on requires a specific configuration, as you would not need to manually configure it again after every commit.

If you select New build for a staging branch, a fresh copy of the production build is created every time a commit is pushed.

A branch that is moved from staging to development is set automatically to Do nothing.

Module installation

You can choose which modules should be installed automatically for development branches.

To change the default behavior, untick the Use Default option under Development build behavior and select one of the following options under Module Installation:

• Install only my modules (does not include submodules): only installs the branch’s modules, excluding submodules. This is the default option.

• Full installation (no test suite): installs the branch’s modules, submodules, and all standard Odoo modules. When running the full installation, the test suite is disabled.

• Install a list of modules: installs the specified modules. To do so, enter their technical name, and separate them using commas (e.g., sale_management,website,accountant).

Nota

If the test suite is enabled, installing all standard Odoo modules can take up to one hour.

Test suite

By default, the test suite for development branches is enabled. You can restrict which tests are run by entering test tags and separating them using commas (e.g., custom_tags,at_install,post_install).

To disable the test suite entirely, untick Validate the test suite on new builds.

Odoo version

You can change the version of Odoo for development branches, for example, to test upgraded code or develop features while your production database is in the process of being upgraded to a newer version, by selecting another Version.

By default, Latest is selected as the Revision, and the sources of your Odoo server are updated weekly automatically to benefit from the latest bug, security, and performance fixes.

To choose a specific revision instead, select it using the Revision field.

Advertencia

Revisions expire after three months. You will be notified by email when the revision’s expiration date approaches. If you have not taken any action when it expires, the Revision field is automatically set back to Latest.

Dominios personalizados

You can configure additional <name>.odoo.com domains or your own custom domains for all branch types.

To use your own custom domain, it is necessary to:

• Own or purchase the domain name.

• Enter the domain name under Custom domains (e.g., www.mycompany.com), then click Add domain.

• Configure the domain name (e.g., www.mycompany.com) using your registrar’s domain name manager with a CNAME record value set to your production database domain name (e.g., mycompany.odoo.com).

Importante

Bare domains (e.g., mycompany.com) are not accepted. They can only be configured using A records, which only accept IP addresses as their value. Therefore, a bare domain could suddenly cease to function, as the IP address of a database can change (e.g., following an upgrade, a hardware failure, a change of database hosting location).

To have both your bare domain (e.g., mycompany.com) and www domain (e.g., www.mycompany.com) working, it is necessary to redirect the bare domain to the www domain. .com. Most domain managers provide a way to configure this redirection, commonly referred to as a web redirection.

HTTPS/SSL

If the redirection is correctly set up, an SSL certificate is automatically generated using Let’s Encrypt within the hour, meaning your domain will be accessible through HTTPS.

SPF and DKIM compliance

If the domain of your email addresses uses the SPF or DKIM authentication protocol, it is necessary to authorize Odoo as a sending host in the domain name settings to increase the deliverability of outgoing emails. For more information, refer to the Configure DNS records to send emails in Odoo documentation.

Importante

If Odoo is not authorized as a sending host, your outgoing emails may be flagged as spam.

Comandos de shell

In the top right corner of the view, several shell commands are displayed. The commands can be copied using the clipboard button and then used in a terminal. In addition, some of them can be used directly from Odoo.sh’s interface.

Clonar

The clone command is used to create a local copy of your Git repository.

Example

git clone --recurse-submodules --branch development [email protected]:my-organization/my-repository.git

• --recurse-submodules to download the submodules of your repository

• --branch main to check out to a specific branch of the repository (e.g., development)

Nota

The run button is not available as the command is used to create a local copy on your machine.

Bifurcar

The fork command is used to create a new branch based on the current one.

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main a command to create a new branch (e.g., development-1) based on the current branch (e.g., development)

• git push -u origin development-1 a command to upload the new branch (e.g., development-1) to the remote repository

Fusionar

The merge command is used to combine changes on one branch into another branch.

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 a command to merge the changes of the current branch into another branch (e.g., staging-1)

• git push -u origin staging a command to upload the merged changes to the remote repository branch (e.g., staging)

SSH

The SSH command is used to connect to a build using SSH.

To use the SSH command, it is necessary to set up an SSH key first. To do so:

• Generate a new SSH key.

• Copy the SSH key to your clipboard.

• On Odoo.sh, click your GitHub user in the top-right corner and select Profile.

  

• Paste the SSH key under the Add a key manually field and click Add.

  

Example

ssh [email protected]

• 25004381 the build ID

• my-user-my-repository-staging-25004381.dev.odoo.com the domain used to connect to the build

Provided you have the necessary access rights on the project, you will be granted SSH access to the build.

Nota

Long-running SSH connections are not guaranteed. Idle connections can be disconnected to free up resources.

Submódulo

The submodule command is used to add a branch from another repository to your current branch as a submodule.

Ver también

Submodules documentation

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> a command to add a specific branch (e.g., master) of a repository (<URL>) as a submodule under the specified path (<PATH>) in your current branch.

• git commit -a a command to commit all current changes

• git push -u origin staging a command to upload the changes of the current branch (e.g., staging) to the remote repository.

Eliminar

The delete command is used to delete a branch from your repository.

Nota

Once you delete a branch, there is no way to retrieve it unless a backup exists. Staging branches are not automatically backed up, but can be manually. Development branches cannot be backed up.

Example

git push origin :staging && git branch -D staging

• git push origin :staging a command to delete a specific branch (e.g., staging) on the remote repository

• git branch -D staging a command to delete the specific branch on your local copy of the repository

Advertencia

Before deleting a branch, refer to the Backups section to better understand how they work and when you should create a manual backup.