Cómo llega el trabajo a tu repositorio.

Cada solicitud se convierte en un ticket con su tamaño

Un ingeniero convierte tu solicitud en tickets, uno por funcionalidad, y le asigna a cada uno un tamaño: pequeño, mediano o grande. Apruebas cada ticket con ese tamaño en tu portal de cliente, el Front Desk. No se trabaja en nada antes de que lo apruebes, y un ticket cuyo tamaño cambia necesita de nuevo tu aprobación.

Todas las funcionalidades se desarrollan. A veces, al trabajar en un ticket, encontramos un problema en su especificación: un caso que nadie describió, dos reglas que se contradicen, una decisión que solo tú puedes tomar. Entonces cerramos ese ticket con el motivo y abrimos uno nuevo con la especificación corregida; el ingeniero vuelve a asignarle un tamaño y tú lo apruebas antes de que empiece el trabajo. Un ticket cerrado no consume créditos.

Dónde se hace el trabajo

El trabajo en un ticket se hace en dos fases.

1. El desarrollo. Nuestra línea de producción con IA escribe la funcionalidad, sus pruebas y su documentación, y ejecuta las pruebas que le corresponden. Esto se ejecuta en nuestra infraestructura en Amazon Web Services.
2. El control. En nuestras propias máquinas en Tailandia, primero se fusiona en el trabajo la última versión de tu rama principal. Después se compila toda tu app y se ejecuta toda su batería de pruebas, antiguas y nuevas, sobre ese árbol fusionado.

Solo un control en verde sigue adelante. Un control en rojo nunca llega a tu repositorio.

Cómo se ve mientras funciona

Este es el panel de nuestra línea de producción, en un proyecto de ejemplo. Cada ticket muestra su tamaño y sus créditos, en qué punto está —desarrollo, fusión de tu rama principal, control, entregado— y qué fue lo último que hizo. Debajo: el ticket que espera tu decisión, los entregados con sus pull requests y uno cerrado y luego vuelto a especificar.

Cómo llega a tu repositorio

Cada ticket entregado es un pull request hacia tu rama de integración. Una vez que el control está en verde, el pull request lleva una comprobación de estado llamada forge/verify, y se fusiona con un merge commit.

• Sin force-push ni commits directos en tu rama principal.
• Sin excepciones de administrador ni fusión automática: cada fusión pasa por la protección de tu rama.
• Si tu app aún no tiene pruebas, los primeros tickets las añaden, con su tamaño y su precio, como cualquier otra funcionalidad.

La protección de tu rama es la regla

Te pedimos un único ajuste en tu rama principal: una comprobación de estado obligatoria, forge/verify, que exija que la rama esté actualizada antes de fusionar y que se aplique también a los administradores.

Volvemos a leer la protección de tu rama justo antes de cada fusión. Si ha cambiado, no fusionamos.

Qué te dice cada entrega

Cada ticket tiene una nota de entrega en el Front Desk:

• el pull request, con un enlace;
• qué se verificó: la compilación y la batería de pruebas completa, sobre el árbol fusionado;
• qué cambió: líneas de código, de pruebas y de documentación;
• los créditos que consumió.

Un ticket cerrado muestra en su lugar el motivo, y no consume créditos. Un informe diario resume lo que avanzó.

App nueva o app existente

App nueva. El repositorio está en nuestro lado mientras se desarrolla la app, y luego se te transfiere con todo su historial.

App existente. Trabajamos directamente en tu repositorio, mediante pull requests, con las reglas anteriores. El código sigue siendo sencillo y estándar, para que cualquier desarrollador pueda retomarlo.

Preguntas

Escribe a sales@hikaro-studio.com o háblanos de tu app: el ingeniero que definiría su alcance te responde en un plazo de un día hábil.