¿Cuánto tarda vuestra propia batería de pruebas?

Veintidós segundos para ciento sesenta y cuatro pruebas y cuatro mil doscientas ochenta y ocho comprobaciones. Por debajo del minuto la gente la lanza sin pensarlo; por encima de diez la esquiva. La duración decide si la herramienta se usa.

¿Podremos publicar nosotros mismos?

Sí, y es el objetivo declarado. Si cada salida depende de que estemos disponibles, habéis cambiado un problema técnico por uno de agenda. Dejamos el procedimiento escrito, ejecutable desde vuestro repositorio y probado por alguien de vuestro equipo antes de cerrar.

¿Con qué tecnologías montáis todo esto?

Laravel en el servidor y React o Next.js en la interfaz, según pida el proyecto. La parte de comprobación y publicación es casi idéntica: cambia el lenguaje, no la idea de no fusionar nada que esté en rojo.

WEB WebCoding · Austin

Desarrollo web en Austin

Construimos webs y plataformas para empresas estadounidenses desde Vilanova i la Geltrú. Lo nuestro se nota menos en el código que en la frecuencia: veinte cambios pequeños antes que uno enorme.

Pide presupuesto sin compromiso WhatsApp directo

Respondemos el mismo día · Presupuesto en 24 h · Agencia con sede en Vilanova i la Geltrú

Diseño y Desarrollo Web en Austin

Cómo trabajamos en Austin

El mismo nivel técnico y de proceso que aplicamos en proyectos de cualquier escala. Lo que cambia es el conocimiento del mercado local.

El equipo de WebCoding programando en la oficina de Vilanova i la Geltrú

Veinte cambios pequeños se arreglan mejor que uno grande

Cuando una publicación reúne dos meses de trabajo, cualquier avería obliga a rastrear cientos de líneas para dar con la culpable. Si ese trabajo sale en veinte tandas, el problema queda encerrado en la última y se localiza en minutos. El tamaño del paquete pesa más que la pericia del revisor.

Que una función esté probada no significa que se pueda comprar

El cálculo del total puede estar impecable y la compra seguir rota, porque falla el salto entre dos pantallas. Por eso hay dos clases de prueba: una examina una pieza aislada, otra recorre el camino entero hasta la confirmación. La segunda es más lenta y la única que contesta lo que importa.

La revisión automática ocurre antes de fusionar, no después

Cada propuesta de cambio dispara la batería entera, el análisis estático y el formateo del código. Si algo sale en rojo, no entra. Eso retira de la mesa la discusión sobre comas y sangrías, y deja la lectura humana para lo que ninguna máquina juzga: si el enfoque elegido era el bueno.

Cuando publicar es una ceremonia, se pospone

Si sacar una versión exige una tarde entera, una lista en papel y alguien disponible, todo el mundo acumula cambios para no repetir el trámite. Automatizar ese paso lo convierte en un botón, y el efecto real no es ahorrar la tarde: es que nadie aplace una corrección de dos líneas.

Resolvemos dudas