Releases y pruebas

Guía completa en la pantalla /releases/como-funciona (botón "Cómo funciona" en la lista de releases).

• Release: una versión de un proyecto (ej.: App 2.4.0), con fecha prevista, issues vinculadas, ciclos de prueba y notas de la versión (un borrador generado de las issues resueltas, editable, para copiar o enviar al cliente).
• Camino de la release (estado): Planificada (planned: en el plan, nadie trabajando todavía) → En desarrollo (in_development: el equipo hace las issues) → En prueba (staging: QA prueba en ciclos de prueba; antes se llamaba Homologación) → Aprobada (approved: el gate registró APPROVED, lista para salir) → En producción (production: salió). Cancelada (cancelled) sale del camino y puede volver a Planificada. El PO/PM mueve el estado; Aprobada normalmente viene de la decisión APPROVED del gate; En producción exige el gate APPROVED (sin él, solo un admin, con justificación), menos en la OTA.
• Cuál está en producción y cuál es la próxima (el momento de la release): versión y OTA son carriles separados: en cada proyecto, la versión más reciente en producción es la versión en producción y la OTA más reciente en producción es la OTA en producción (current, "En producción"); las demás en producción del mismo carril son anteriores (previous). La próxima (is_next, sello "Siguiente") es la que sale después en su carril: la más avanzada en el camino (Aprobada, después En prueba, En desarrollo, Planificada) y, en empate, la de fecha prevista más temprana. La lista de releases se separa en En producción, En prueba (incluye Aprobadas), Siguientes y Anteriores (incluye Canceladas).
• Actualización sin tienda (OTA): una release con tipo (kind) "ota", para lo que llega a los dispositivos sin pasar por la App Store o la Play Store. Crea una release nueva para cada OTA, con la versión que lleva (ej.: 2.4.1) y el build. Puede seguir el camino con ciclo de prueba y gate, pero no hace falta: un hotfix por OTA sale en horas y QA lo valida después, ya en producción. Por eso la OTA va a En producción desde cualquier paso, sin decisión en el gate, y hasta se puede crear directamente como En producción (estado "production") cuando ya se envió. Cualquier release que ya salió fuera de tracker (deploy del backend, versión publicada antes) también puede nacer En producción, con la fecha en que salió. Su página muestra la validación por las issues vinculadas: cuántas están en Listo para QA, En prueba, Aprobado y Rechazado. Publicada, pasa a ser la OTA en producción del proyecto y la OTA anterior va a Anteriores; la versión de la tienda sigue en producción, porque son carriles separados. Una versión normal (tienda o deploy) es kind "version", la de por defecto.
• En la página de la release, la parte de arriba dice en una frase dónde está, cuál está en producción y cuál es el próximo paso (ej.: crear un ciclo de prueba, terminar las pruebas, corregir lo que falló, registrar APPROVED, publicar).
• Issue y release: el campo Release de la issue dice en qué versión sale (la release principal), normalmente de su proyecto; cuando la corrección sale solo en otro proyecto (el deploy de la plataforma, por ejemplo), la principal puede ser la release de allá; la tarjeta del tablero y la issue muestran, por ejemplo, "Sale en la 2.4.0 · en prueba". Cuando la misma corrección sale en más de un lugar (deploy del backend, la OTA de cada runtime, consola), las demás releases entran en "También sale en", de cualquier proyecto de la empresa. La issue aparece en todas: en la lista de la release, en el gate, en las notas de la versión y en la validación. La "Versión corregida" del registro técnico es solo la anotación del dev sobre el build de la corrección.
• Caso de prueba: un guion con pasos y resultado esperado, reutilizado en cada versión. Ciclo de prueba: una ronda de pruebas de una release; cada caso recibe aprobado, falló o bloqueado, y un FAIL puede abrir una issue ya completada.
• Release Gate: la decisión de QA de liberar (APPROVED) o retener (BLOCKED) la versión. La app sugiere APPROVED cuando hay un ciclo de prueba con casos, todas las pruebas pasaron y no hay una issue S1 abierta; una S2 abierta solo genera un aviso.