Indicador luminoso de construcción

Con el crecimiento de la integración continua a las pruebas continuas , el número de objetivos de compilación simultáneos puede aumentar, incluso para una sola base de código. Además de un objetivo de compilación simple, ahora habrá pruebas unitarias y varios niveles de pruebas de sistema. Como las pruebas extensas son lentas y es deseable mantener las pruebas rápidas ejecutándose en un ciclo rápido para brindar retroalimentación rápida a los desarrolladores, el número de objetivos de compilación puede aumentar a cincuenta o más. Esto es demasiado para mostrarlo con una simple pantalla de lámpara de lava. Los servidores de integración como Jenkins ofrecen un panel de control accesible a través de la web, que puede mostrarse permanentemente en un monitor de pantalla plana montado en la pared. Los detalles de dicho panel son demasiado pequeños para leerse desde el otro lado de la oficina, pero los cambios de color presentan una visión general del estado.

Con una metodología de desarrollo continuo guiado por pruebas , se publican nuevas pruebas antes de que se desarrolle el código funcional para superarlas. Por lo tanto, existe un período en el que se sabe, e incluso se requiere, que algunas pruebas fallen. ^{[ 6 ]} Las pruebas fallidas son necesarias, ya que demuestran la capacidad de las nuevas pruebas para detectar la situación problemática. Una vez que el nuevo código se desarrolla y funciona, estas pruebas comienzan a pasar. Un entorno de pruebas continuas en el que se publican nuevas pruebas antes que su código requiere, por lo tanto, dos objetivos de compilación: uno que rastrea el código y las pruebas más recientes, y otro "candidato a lanzamiento" que solo se actualiza en incrementos cuando todas las pruebas se cumplen con el código que las supera. Para el indicador de compilación, esto también implica que uno de esos objetivos se mostrará frecuentemente como "fallando" sus pruebas. Como este "fallo" anticipado podría ser engañoso para observadores ingenuos, el indicador de compilación debería ocultarlo o presentarlo claramente.

Cuando varios objetivos de código, como versiones antiguas de productos, aún son compatibles con la integración continua (CI), pero no se encuentran en un desarrollo activo, un panel de control completo puede verse dominado por objetivos obsoletos que rara vez cambian. En este caso, un panel de control selectivo puede ser más apropiado, donde solo se muestran los objetivos que están fallando o que han estado activos recientemente. El panel de control completo está disponible en los escritorios de los desarrolladores, pero la pantalla principal muestra solo los aspectos más destacados. Estos paneles de control suelen codificarse localmente extrayendo información del panel principal y aplicándole filtros locales relevantes, según las necesidades locales. Una desventaja de un panel de control con filtros dinámicos, en comparación con uno estático, es que la posición de los iconos de un objetivo específico puede cambiar en la pantalla, lo que dificulta su lectura desde cualquier punto de la oficina. En este caso, se pueden mostrar iconos distintivos, como el logotipo del producto, en lugar de simples bloques de color.