¿Qué es la integración continua y para qué sirve?
Una web puede seguir viéndose bien y haber dejado de funcionar donde importa.
Imagina una actualización del formulario de contacto. Los campos están en su sitio, el botón conserva su color y la página carga. Pero al enviar una consulta aparece un error. O el mensaje llega dos veces. O alguien que navega con teclado ya no puede alcanzar el botón.
Es un ejemplo sencillo, pero explica una parte del desarrollo que rara vez aparece en una propuesta comercial: cómo comprobamos que una mejora conserva lo que ya funcionaba.
En MaisMedia dedicamos trabajo a eso. A construir, a optimizar y a revisar las consecuencias de cada cambio. La integración continua (CI, por sus siglas en inglés) forma parte de ese proceso en nuestros proyectos de software.
Para quien tiene un negocio, lo relevante es entender qué se comprueba, cuándo se comprueba y qué ocurre si algo falla.
Cómo funciona la integración continua
La integración continua consiste en incorporar cambios con frecuencia a una base de código compartida y comprobar su funcionamiento mediante procesos repetibles. Esas comprobaciones pueden ejecutarse automáticamente cuando se sube código o se propone una modificación, como explica la documentación de GitHub sobre CI.
En la práctica, permite formular preguntas concretas:
¿Se puede construir la aplicación? ¿Sigue funcionando una operación que ya estaba probada? ¿La actualización es compatible con las versiones que admitimos? ¿Han aparecido problemas que nuestras comprobaciones saben detectar?
Los cambios pequeños también ayudan a investigar. Si una prueba funcionaba antes y falla después de una modificación acotada, hay menos terreno que revisar.
Conviene distinguir tres momentos: comprobar un cambio, decidir si se acepta y publicarlo. La CI aporta información para tomar esa decisión. Para impedir automáticamente que se incorpore código con pruebas fallidas hay que configurar también las reglas correspondientes del repositorio.
Tener un proceso automático no significa tener todas esas decisiones resueltas.
Cómo lo aplicamos en proyectos de MaisMedia
Nuestros proyectos tienen necesidades distintas. Una herramienta que otras personas instalan, una aplicación con usuarios y una web corporativa requieren comprobaciones diferentes.
Estos son tres ejemplos de nuestro trabajo.
a11y.es: comprobar lo que ocurre en el navegador
En a11y.es tenemos un flujo de integración continua configurado para ejecutarse al proponer cambios y al actualizar la rama principal. Prepara las dependencias, revisa el código y ejecuta las pruebas.
También instala Chromium, porque parte de lo que necesitamos comprobar requiere un navegador real.
El HTML puede contener un botón con su etiqueta correcta y, aun así, mostrarlo con un contraste insuficiente. Una tabla puede funcionar en escritorio y desbordar la pantalla de un móvil. El modo oscuro puede introducir una combinación de colores que no existía en el claro.
Por eso nuestras pruebas de accesibilidad incluyen páginas renderizadas con sus estilos, en tamaños de escritorio y móvil, y en ambos esquemas de color. Hay además comprobaciones específicas de teclado, ampliación del texto y adaptación a pantallas estrechas.
Son pruebas con un alcance definido. Ayudan a detectar determinadas barreras; la revisión humana sigue siendo necesaria para valorar el uso completo de la aplicación.
Hay un detalle que nos parece especialmente importante: también comprobamos que el detector detecta errores. Una de las pruebas utiliza deliberadamente HTML con problemas conocidos y exige que la herramienta los encuentre.
Si el mecanismo de revisión deja de funcionar, queremos enterarnos. Una ejecución sin avisos solo resulta útil cuando sabemos que se han realizado las comprobaciones previstas.
Esta forma de trabajar está relacionada con lo que explicamos al presentar a11y.es y su enfoque de accesibilidad verificable: acompañar las afirmaciones con evidencia que pueda revisarse.
a11y-toolkit: probar también lo que se entrega
En a11y-toolkit, nuestro proyecto abierto de herramientas de accesibilidad, las comprobaciones incluyen distintas versiones de Python, la construcción del paquete y una prueba de instalación.
Esto último importa más de lo que parece.
Un programa puede funcionar dentro de la carpeta donde se desarrolla porque allí están todos sus archivos. Al preparar el paquete que instalarán otras personas, alguno puede quedarse fuera. El código sigue estando, pero falta un recurso necesario.
Nuestro flujo comprueba, entre otras cosas, que determinados datos del motor sobreviven a la instalación. También ejecuta una operación de la herramienta instalada y verifica que sus componentes pueden cargarse.
Es una comprobación cercana a lo que recibirá quien la utilice.
El flujo de CI de a11y-toolkit es público. Se puede consultar qué ejecuta, sobre qué versiones y con qué condiciones. Esa posibilidad de inspeccionar el trabajo también forma parte del valor del software abierto.
maismedia.com: revisar antes y después de publicar
Nuestra propia web aporta otro ejemplo, con una distinción importante: el procedimiento que tenemos documentado combina compilación y verificaciones de publicación. Eso no equivale, por sí solo, a un flujo completo de CI automatizado en un servidor.
Al generar maismedia.com se preparan las páginas, el tratamiento de imágenes, el índice de búsqueda y la política de seguridad de contenidos. Una de las comprobaciones de ese proceso puede hacer fallar la compilación si encuentra una discrepancia en los hashes de determinados scripts.
Después de publicar, el procedimiento exige revisar las páginas afectadas en el dominio real: que respondan, que contengan el cambio esperado y, cuando corresponde, que sus recursos estén disponibles.
Una compilación correcta demuestra que se ha podido generar una versión. Todavía queda comprobar qué está sirviendo el sitio.
Esta disciplina conecta con nuestra checklist pública de entrega. La checklist reúne criterios que revisar; la automatización permite repetir algunos de ellos. Ambos recursos se complementan.
Qué gana el cliente con estas comprobaciones
El valor aparece cuando relacionamos la prueba con el problema que ayuda a detectar.
| Comprobación | Qué ayuda a detectar | Por qué importa |
|---|---|---|
| Construcción de la aplicación | Errores que impiden generar una versión utilizable | Permite investigar antes de intentar publicarla |
| Pruebas de comportamiento | Cambios que alteran una operación conocida | Ayuda a conservar funciones que el negocio utiliza |
| Revisión en navegador | Determinadas barreras de accesibilidad o problemas de presentación | Permite encontrar dificultades de uso en las condiciones probadas |
| Instalación del paquete | Archivos o componentes que faltan en la entrega | Comprueba una situación más cercana a la del usuario |
| Verificación después de publicar | Diferencias entre la versión preparada y la web disponible | Ayuda a confirmar que el cambio ha llegado correctamente |
No todas las webs necesitan la misma cantidad de pruebas. Lo razonable es empezar por las operaciones que sostienen el negocio y las consecuencias de que fallen.
En una tienda, el proceso de compra merece especial atención. En una empresa de servicios, puede ser el envío de consultas. En una aplicación, el acceso a la cuenta o la conservación de los datos.
Esa selección requiere conocer el proyecto. Una batería enorme de comprobaciones poco relevantes puede aportar menos que unas pocas pruebas bien elegidas.
Con IA, verificar cobra todavía más importancia
La inteligencia artificial permite avanzar más deprisa en muchas tareas de desarrollo. En MaisMedia la utilizamos como parte del trabajo, con revisión y criterio técnico.
Esa velocidad obliga a cuidar cómo evaluamos el resultado.
Un cambio puede parecer razonable al leerlo y contener una suposición equivocada. También puede resolver el problema solicitado y modificar otro comportamiento que debía conservarse.
Las pruebas permiten contrastar parte de ese resultado con condiciones definidas: qué debería ocurrir, con qué datos y en qué circunstancias.
Pero también hay que revisar las propias pruebas. Si se redactan para aceptar exactamente lo que acaba de producir el código, pueden confirmar el mismo error. Deben partir de lo que necesita el proyecto y de comportamientos que sabemos que deben mantenerse.
La responsabilidad sobre lo que entregamos sigue siendo nuestra. Incluye decidir qué automatizamos, interpretar los resultados y revisar lo que queda fuera de esas comprobaciones.
Qué significa realmente que todo esté en verde
Un resultado verde significa que las comprobaciones ejecutadas han superado sus condiciones.
Su valor depende de qué se haya probado, de cómo estén diseñadas esas pruebas y de si se han ejecutado realmente. Algunas comprobaciones requieren un navegador u otros componentes; si faltan, pueden omitirse. Por eso también importa revisar las pruebas saltadas y el entorno de ejecución.
Hay límites que conviene explicar con claridad.
Una batería de pruebas no garantiza que una web sea completamente segura. Una auditoría automática no acredita por sí sola toda su accesibilidad. Y una aplicación puede superar las pruebas previstas y resultar confusa para quien intenta utilizarla por primera vez.
También hay decisiones que exigen contexto: si un mensaje se entiende, si el recorrido responde a las necesidades del cliente o si una operación debería existir de otra manera.
En nuestro trabajo de accesibilidad web, esa combinación entre comprobaciones automáticas y revisión humana es especialmente importante. Lo que una herramienta detecta resulta valioso; lo que no detecta sigue necesitando atención.
Mostrar ambas cosas ayuda a construir una relación profesional más clara. Nuestra página de transparencia reúne parte de ese trabajo y de nuestros criterios públicos.
Cinco preguntas que merece la pena hacer
Si vas a contratar el desarrollo o el mantenimiento de una web, estas preguntas pueden ayudarte a valorar cómo se cuidará después:
- ¿Qué funciones importantes se comprueban cuando hacemos cambios? Pide ejemplos relacionados con tu negocio.
- ¿Qué sucede si falla una prueba? Conviene saber quién revisa el fallo y qué impide que el cambio llegue a publicarse.
- ¿Qué se revisa manualmente? La respuesta debería explicar los límites de la automatización.
- ¿Cómo comprobáis que la publicación ha salido bien? Preparar una versión y verla funcionar en el dominio real son pasos distintos.
- ¿Cómo recuperaríamos el servicio si algo sale mal? Debe existir un procedimiento adecuado al proyecto y a los datos que maneja.
Una web útil necesita poder evolucionar. Cambian los contenidos, las herramientas, los servicios de la empresa y las expectativas de quienes la visitan.
En MaisMedia entendemos el desarrollo web con esa continuidad: construir una base que podamos mantener, comprobar y mejorar. La integración continua aporta una parte de ese trabajo. El criterio está en elegir qué merece comprobarse y actuar sobre lo que encontramos.