POLITICA DE COOKIES

Q2BSTUDIO.COM utiliza cookies técnicas, analíticas, de sesión y de publicidad con la finalidad de prestar un mejor servicio. No obstante, necesitamos su consentimiento explícito para poder utilizarlas. Así mismo puede cambiar la configuración de las cookies u obtener más información aquí .

Pruebas Colaborativas Previas a la Fusión para Múltiples PR

Pruebas colaborativas previas a la fusión para múltiples PR

Publicado el 03/09/2025

Lee este tutorial en Signadot.

Cuando una nueva funcionalidad toca varios microservicios, probar antes de fusionar se vuelve complejo. Cambios coordinados en PRs separadas deben validarse juntos. En esta guía práctica construimos con Signadot un sistema automatizado que crea entornos efímeros y unificados de previsualización para todas las PRs asociadas a un mismo epic de producto.

Qué aprenderás paso a paso: preparar HotROD y Signadot para pruebas colaborativas pre merge, diagnosticar problemas reales, automatizar entornos efímeros con GitHub Actions e implementar y verificar una funcionalidad multi servicio llamada Recargos Dinámicos.

Los archivos de configuración y el código de ejemplo están disponibles en este repositorio.

1. Requisitos y entorno base

Instala la demo HotROD siguiendo el README del repo oficial de HotROD. Los manifiestos YAML ya incluyen las anotaciones necesarias para integrarse con Signadot. Clona el repo, entra en la carpeta y sigue los pasos del README de HotROD.

Verifica el baseline conectándote al clúster con signadot local connect --cluster tu cluster y accede al frontend con la URL interna https://frontend.hotrod.svc:8080. Solicita un viaje y confirma que aparece un coche en el mapa.

2. Escenario Recargos Dinámicos

Implementaremos Recargos Dinámicos en la app HotROD. Esto exige cambios en backend servicio route y en el frontend. Todo el trabajo se rastrea bajo el epic EPIC 42.

Backend route: añade en route.proto los mensajes SurchargeRequest pickup y dropoff y SurchargeResponse amount, y declara el RPC GetSurcharge. Implementa en server.go un handler que registre la petición y devuelva 1.25 como recargo fijo a modo de ejemplo. En client.go incorpora el método GetSurcharge con timeout corto y logging, que invoca el RPC y retorna la respuesta.

Frontend: en el servidor Go del servicio frontend, importa el cliente de route, inyecta routeClient en la estructura Server, registra un handler HTTP GET en la ruta slash surcharge que recibe pickup y dropoff, llama a routeClient.GetSurcharge y devuelve un JSON con surcharge. En createServeMux añade el registro de la ruta y en el handler de dispatch invoca GetSurcharge para pasar el valor a la plantilla.

React: en el componente de la home agrega estado surcharge, implementa una función asíncrona que haga fetch a slash surcharge con los parámetros y actualice el estado. Llama a esta función dentro del flujo de solicitar viaje y muestra una caja informativa cuando surcharge tenga valor con el texto Recargo dinámico aplicado y el importe con dos decimales.

Plantilla UI: en index.html añade un bloque que, si existe surcharge, muestre Recargo dinámico aplicado y el valor formateado. Coloca el contenedor de información de viaje debajo.

3. Construir nuevas imágenes Docker

Genera el código Go a partir de los proto con make generate proto, construye el frontend React con make build frontend app y compila la imagen Docker con make build docker. Etiqueta y publica la imagen, por ejemplo docker tag signadot slash hotrod epic 42 surcharge only linux amd64 tu usuario docker slash hotrod epic 42 surcharge only y docker push tu usuario docker slash hotrod epic 42 surcharge only. Usa tu propio namespace o registro.

4. Flujo manual Previsualización unificada con Signadot

Crea dos sandboxes, uno para route y otro para frontend, ambos con label epic EPIC 42 y con la imagen que acabas de subir. Para cada sandbox define cluster, namespace hotrod, fork de la Deployment correspondiente y la personalización de imagen. Aplica los sandboxes con signadot sandbox apply. En el clúster coexistirán baseline y sandbox de cada servicio.

Casos de prueba clave: fe1 con r1 valida baseline, fe1 con r2 comprueba que el nuevo route no rompe el frontend base, fe2 con r1 debe fallar de forma controlada porque faltan APIs, y fe2 con r2 es la prueba end to end de la nueva feature.

Para unificar contextos crea un RouteGroup que haga match por label epic EPIC 42 y defina un endpoint llamado hotrod frontend apuntando a http colon slash slash frontend punto hotrod punto svc colon 8080. Aplica el RouteGroup con signadot routegroup apply. Con la extensión de Chrome de Signadot activa el RouteGroup epic 42 preview y accede a la URL de previsualización hotrod frontend doble guion epic 42 preview punto preview punto signadot punto com. Solicita un viaje y deberías ver Recargo dinámico aplicado 1.25.

5. Automatización con GitHub Actions

Agrega los secretos SIGNADOT API KEY, SIGNADOT ORG y SIGNADOT CLUSTER en la configuración del repositorio. Crea un workflow que en cada pull request construya y publique una imagen etiquetada con el número de PR y aplique un sandbox para el servicio afectado con labels de metadatos del PR. Instala el CLI de Signadot en el job para aplicar el manifiesto del sandbox.

Incorpora un segundo workflow que escuche comentarios en PR. Si el comentario contiene el comando slash epic y un identificador, parsea el EPIC, vuelve a aplicar el sandbox añadiendo la label epic y crea o actualiza un RouteGroup que haga match por epic y por el PR. Publica un comentario en la PR con la URL de previsualización unificada. Este patrón habilita entornos efímeros por PR y vistas unificadas por epic sin intervención manual.

Notas profesionales: estos flujos siguen buenas prácticas de Signadot y funcionarán aportando parámetros válidos, secretos correctos e imágenes existentes. Ajusta los manifiestos a tus nombres de clúster, namespaces, despliegues y pipelines de build. Recomendamos definir convenciones de etiquetado claras para agrupar sandboxes por epic y por PR.

Conclusión: con Signadot puedes orquestar pruebas colaborativas pre merge para funcionalidades que atraviesan múltiples PRs y microservicios. Los sandboxes aíslan cambios por servicio, los RouteGroups unifican contextos bajo una sola URL y GitHub Actions automatiza la creación y el ciclo de vida de estos entornos. Escala desde pruebas manuales hasta una plataforma de previsualización continua cercana a producción.

Sobre Q2BSTUDIO: en Q2BSTUDIO impulsamos a empresas con aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, servicios inteligencia de negocio, agentes IA e implantaciones con Power BI. Podemos ayudarte a diseñar pipelines CI CD, entornos efímeros y observabilidad para que tus equipos integren y prueben funcionalidades complejas con seguridad y velocidad. Descubre cómo abordamos proyectos de software a medida y aplicaciones a medida o cómo llevamos la inteligencia artificial en empresas a producción con buenas prácticas en ciclo de vida, MLOps y gobierno del dato.

Fin del artículo, inicio de la diversión
Construyendo software juntos

Dando vida a tus ideas desde 2008

Diseñamos aplicaciones móviles y de escritorio innovadoras que cumplen con tus requisitos específicos y mejoran la eficiencia operativa.
Más info
Cuéntanos tu visión
Sea cual sea el alcance, podemos convertir tu idea en realidad. Envíanosla y charlemos sobre tu proyecto o una colaboración futura.
Contáctanos
artículos destacados
Live Chat
Enviado correctamente.

Gracias por confiar en Q2BStudio