Saltar al contenido

El ensayo general

La práctica que elimina la mayoría de las sorpresas: compilar como en producción de forma rutinaria, con una lista de comprobación corta, y en una máquina que no sea la tuya. Cuándo hacerlo y qué mirar.

El perfil intermedio

Antes de la rutina, la herramienta. Compilar con el perfil de depuración pero empaquetando da lo mejor de los dos modos:

Shell
bun run tauri build --debug

Eso produce un instalador de verdad, con el frontend servido por el protocolo interno —así que reproduce los cinco fallos del origen— pero con símbolos, sin optimizaciones y con las herramientas de desarrollo disponibles. Es decir: producción por dentro, y se puede mirar.

Es más rápido de compilar que la versión optimizada, así que sirve para el ensayo frecuente. La versión completamente optimizada se reserva para lo que de verdad se publica.

La cadencia

Tres momentos, y ninguno interrumpe el trabajo:

En cada cambio, automáticamente. El trabajo rápido de integración continua del nivel 9.5: compilar sin empaquetar en las tres plataformas. No prueba la aplicación, pero caza el fallo de compilación específico de un sistema, que es el que más se escapa.

Una vez por semana, a mano. El ensayo general con el perfil intermedio, en tu máquina, con la lista de abajo. Diez minutos, viernes por la tarde.

Antes de cada versión, completo. La compilación optimizada de verdad, en las tres plataformas, instalada desde el instalador —no ejecutada desde el directorio de compilación— y en una máquina que no sea la tuya.

La distinción entre el segundo y el tercero importa: el ensayo semanal caza los fallos del catálogo; el previo a la versión caza los del entorno, que solo aparecen en una máquina limpia.

La lista de comprobación

Cinco minutos, y en este orden porque va de lo más frecuente a lo menos:

La máquina que no es la tuya

Para el ensayo previo a una versión, la lista de arriba no basta: hace falta ejecutarla en una máquina que no tenga tu entorno. Cuál, en orden de rentabilidad:

  1. Una máquina virtual con la distribución de Linux más antigua que soportes. Es la que más fallos caza, con diferencia, por todo lo del nivel 3.4. Si solo puedes tener una, que sea esta.
  2. Un Windows sin herramientas de desarrollo instaladas. Caza el fallo del componente de webview ausente y los problemas de permisos de directorio.
  3. Un macOS con la versión mínima que declaraste soportar. Caza las características de la interfaz que el motor de esa generación no tiene.

Y una precisión que se olvida: instalar desde el instalador, no ejecutar el binario del directorio de compilación. Son cosas distintas: el instalador coloca los recursos en su sitio definitivo, registra los tipos de fichero y los esquemas de URL, y aplica los permisos del sistema. Ejecutar el binario suelto se salta todo eso, y precisamente ahí viven varios de los fallos que buscas.