Tema: continuous-integration
-
Diseñar un pipeline de integración continua
Un pipeline de CI debería ser rápido, autocomprobable e idéntico para cada cambio: compilar desde un checkout limpio, ejecutar linters y pruebas por etapas, fallar con claridad, y mantener el tiempo total lo bastante corto para que se espere a que termine.
-
Mantener idénticas las comprobaciones locales y las de CI: un único punto de entrada, herramientas fijadas, el mismo contenedor
Una comprobación que pasa localmente debería pasar en CI y viceversa: definir cada comprobación una sola vez como una tarea con nombre, fijar la cadena de herramientas en un manifiesto versionado del que instalen tanto el arranque como el pipeline, ejecutar CI en la misma imagen de contenedor que el entorno de desarrollo, fijar la configuración regional y la zona horaria, y tratar cualquier fallo exclusivo de CI como un defecto de paridad que eliminar antes de corregir el síntoma.
-
Bases de datos efímeras en contenedores para pruebas de integración
Iniciar el motor de base de datos real en un contenedor desechable por cada ejecución de pruebas, mantener sus datos en memoria, aplicar las migraciones una sola vez a una base de datos plantilla y copiarla por cada archivo de pruebas; así las pruebas ejercitan el planificador real, las restricciones y el comportamiento de aislamiento en lugar de un sustituto en memoria.
-
Orden de dependencias mediante recorrido de grafos: BFS, DFS y ordenamiento topológico
Modelar las dependencias como un grafo dirigido, usar un recorrido en anchura o en profundidad para encontrar todo lo afectado por un cambio, y el algoritmo de Kahn o el posorden de DFS para producir un orden de compilación o migración que reporte los ciclos en lugar de ocultarlos; graphlib y tsort implementan el ordenamiento.
-
Ejecutar pruebas de mutación sin ahogarse en supervivientes
Ejecutar una herramienta de mutación sobre un módulo, clasificar cada mutante superviviente como una aserción faltante, un caso faltante o un mutante equivalente, corregir los dos primeros, excluir el tercero, y acotar el tiempo de ejecución con ejecuciones incrementales o limitadas al diff; usar la puntuación como un trinquete por módulo en lugar de un objetivo global.
-
Pruebas automatizadas de videojuegos: combina comprobaciones headless con evidencia de renderizado
Diseña una suite práctica de pruebas para un videojuego con pruebas de lógica aisladas, comprobaciones reproducibles de escenas y comparaciones controladas de capturas de pantalla, con políticas claras para fallos y baselines.
-
¿Qué comprobaciones previas al despliegue han detenido realmente una versión defectuosa en el último año, y cuáles nunca se han activado?
Pregunta abierta: las canalizaciones (pipelines) acumulan controles (pruebas, escaneos, comprobaciones de humo, análisis canario, aprobaciones manuales, plazos de despliegue), y la documentación de Kubernetes señala que un Deployment estancado solo se reporta, no se revierte; qué controles tienen un historial de haber detenido una versión defectuosa, cuáles nunca se activaron, y cuáles solo se activaron por falsos positivos.
-
Pruebas de contrato dirigidas por el consumidor: verificar integraciones sin un entorno compartido
Un contrato dirigido por el consumidor registra las solicitudes que hace un consumidor y la respuesta mínima de la que depende; el consumidor prueba contra un mock construido a partir de ese registro, y el proveedor lo reproduce contra su código real. Ambos lados se ejecutan en sus propios pipelines, y una matriz de versiones responde si una versión es compatible con lo que está desplegado.
-
Atestaciones de procedencia de build: qué registra la procedencia SLSA y cómo se verifica
El track Build de SLSA califica cuán confiable es la procedencia de un artefacto, desde "existe procedencia" (L1) hasta una plataforma de build reforzada (L3); la procedencia es una atestación in-toto que nombra los digests del artefacto, quien construyó, el tipo de build y sus parámetros externos, y quien consume la verifica contra una raíz de confianza y valores esperados antes de usarla.
-
Entornos de vista previa por rama: una copia desplegada por pull request, eliminada al hacer merge
Dar a cada pull request una copia en ejecución de la aplicación en su propia URL, construida una vez por commit, nombrada según el número del pull request, poblada con el seed local y conectada a servicios de terceros en sandbox; publicar la URL en el pull request, limitar la concurrencia y eliminar la copia y sus datos al hacer merge, al cerrar o por inactividad.
-
Desarrollo basado en trunk y ramas de corta duración
Integrar el trabajo de todos en una única línea compartida al menos una vez al día, mantener las ramas de corta duración y ocultar el trabajo inacabado tras feature flags reduce los conflictos de fusión y hace realidad la integración continua.
-
Git hooks para comprobaciones locales rápidas
Los hooks del lado del cliente, como pre-commit, ejecutan formateadores y linters rápidos antes de que exista el commit. Ahorran tiempo de revisión, pero deben ser rápidos, no pueden ser la única barrera de control y Git no los versiona por sí mismo.
-
Diagnóstico y eliminación de tests inestables (flaky)
Un test inestable (flaky) pasa y falla sin que cambie el código; las causas habituales son el estado compartido, las suposiciones sobre tiempos, la dependencia del orden y los servicios externos reales. Hay que ponerlo en cuarentena, reproducir el fallo y corregir la causa, nunca limitarse a reintentar.
Legible por máquina: JSON