Prueba antes de actualizar la tienda

JenkinsBeginner
Practicar Ahora

Introducción

Moss & Mallow es una tienda de regalos de barrio ficticia. Su nueva colección de kits de semillas debe conservar el descuento por lote y las reglas de envío existentes. La tienda ya funciona, pero el Pipeline de Jenkins proporcionado puede publicar una versión candidata incluso cuando falla una prueba real de precios.

Leerás el fallo real de la prueba, vincularás el estado de la ejecución de Jenkins con la decisión de publicación y publicarás la versión candidata que funciona correctamente. Este laboratorio presupone que conoces la navegación básica de Jenkins y que puedes reconocer un Pipeline declarativo breve. Explica los nuevos ajustes de informes de pruebas y de control de publicación; no se requiere programar aplicaciones, realizar instalaciones, disponer de una cuenta en la nube ni hacer compras reales.

Usa Gift Shop para recorrer la experiencia del cliente y Jenkins para la configuración y las ejecuciones. Son dos servicios en una misma máquina virtual preparada. Las dos versiones candidatas, broken y fixed, son versiones de prueba proporcionadas. Cada unidad comienza de forma independiente. El tiempo estimado incluye la lectura y los errores habituales, y no se ha medido con principiantes.

Observa qué detiene realmente una prueba fallida

En este paso compararás los precios normales con una prueba real fallida y descubrirás por qué una ejecución inestable de Jenkins aún puede publicar una versión. Empieza en Gift Shop.

Selecciona Find a little gift o Shop en la navegación. Un kit de semillas cuesta £12. Al comprar tres o más kits de semillas se aplica un descuento por lote del 10 %. El envío cuesta £4 y es gratuito cuando el importe de los productos alcanza al menos £40. Los precios son estimaciones; la tienda no acepta pagos.

Establece Quantity del kit de semillas en 3 y selecciona Check basket. El importe normal de los productos es £32.40, el envío es £4.00 y el total es £36.40. Usa Shop para volver. Comprueba también dos cajas de pícnic: el importe de los productos es £40.00 y el envío es gratuito. Abre Visit, descarga la tarjeta de cuidados de las semillas y lee el archivo de texto guardado. Estas funciones normales deben seguir disponibles al terminar.

Una versión candidata es una versión que se está considerando para su publicación. Una ejecución es una ejecución individual de Jenkins, con su propio número, parámetros y resultado. Cambia a la pestaña Jenkins. Abre shop-update y selecciona Build with Parameters. Deja RELEASE en broken y selecciona Build. Esta primera ejecución publica deliberadamente una versión candidata incorrecta de práctica para que puedas observar el problema; no afecta a ningún cliente real.

Espera a que termine la ejecución. Abre su entrada numerada en Builds y luego Console Output. El Pipeline tiene tres etapas: Prepare copia la versión candidata elegida en el espacio de trabajo de la ejecución, Test ejecuta las comprobaciones de precios proporcionadas y Publish entrega el paquete a la tienda.

La consola debe incluir estas líneas, cuyo texto es constante:

Pricing failures: 1
Release received
Finished: UNSTABLE

UNSTABLE significa que la ejecución tiene un problema de calidad, como pruebas fallidas. Por sí solo, este estado no impide todas las etapas posteriores. Release received muestra que este Pipeline realizó la publicación de todos modos.

Abre Tests en esa ejecución. Abre la prueba fallida seed_bundle y lee los detalles del fallo:

Expected 3240 400; got 2880 400

Informe real de pruebas de Jenkins: un caso fallido y tres casos superados

Los valores están en peniques: la prueba esperaba £32.40 de productos y £4 de envío, pero la versión candidata calculó £28.80 de productos. Las otras tres pruebas se superaron. Estos resultados proceden de ejecutar el programa real de precios de la versión candidata; el informe XML se genera a partir de esas comparaciones.

Cambia a Gift Shop, usa Shop y comprueba de nuevo tres kits de semillas. Actualiza la página si es necesario. El total incorrecto ahora es £32.80. Has observado una publicación realmente incorrecta, no solo un color de advertencia. Vuelve a la ejecución numerada de Jenkins antes de usar la comprobación de este paso.

Vincula el resultado de la prueba con la publicación

En este paso cambiarás el Pipeline para que una prueba fallida siga siendo visible e impida la etapa Publish. Empieza en Jenkins y abre la página del trabajo shop-update mediante su enlace en la ruta de navegación.

Selecciona Configure y luego la sección Pipeline. Su editor Script contiene un Pipeline declarativo. agent any selecciona un ejecutor disponible de Jenkins; en este entorno introductorio preparado se ejecuta dentro del contenedor del controlador. Un espacio de trabajo es el directorio asignado a esa ejecución. Otro proyecto enseña el uso de agentes independientes.

Lee la etapa Test. La línea proporcionada sh returnStatus: true, script: ... ejecuta el script de pruebas y devuelve su código de salida en lugar de provocar inmediatamente un error del Pipeline. Esto permite que el siguiente paso, junit, publique los detalles de las pruebas. El código de salida cero significa que el script se ejecutó correctamente; un código distinto de cero significa que no fue así. junit lee el archivo XML de resultados, adjunta las pruebas a esta ejecución y normalmente la marca como UNSTABLE cuando falla una prueba.

Una opción del Pipeline cambia la forma en que Jenkins lo ejecuta. Añade la siguiente línea inmediatamente después de agent any. Las llaves agrupan la opción; conserva tanto las de apertura como las de cierre exactamente como se muestran.

options { skipStagesAfterUnstable() }

El principio del script debe tener ahora este aspecto. Conserva todas las demás líneas existentes, incluida la dirección del receptor y las etapas proporcionadas Prepare, Test y Publish.

pipeline {
    agent any
    options { skipStagesAfterUnstable() }

Esta opción omite las etapas posteriores una vez que la ejecución pasa a ser inestable. No convierte una prueba fallida en una prueba superada. Conserva el publicador estándar de informes:

junit testResults: 'reports/pricing.xml'

Conserva las invocaciones de shell proporcionadas para copiar la versión candidata, ejecutar test-shop.sh y publicar el paquete. El informe de pruebas debe proceder de ese ejecutor de pruebas; no lo sustituyas por un paso que escriba un informe ni añadas otros comandos de shell.

No añadas skipMarkingBuildUnstable: true: ese ajuste suprime el estado de ejecución del que depende este control de publicación. No elimines pruebas, no cambies sus precios esperados, no alteres las versiones candidatas ni el publicador proporcionados y no omitas la publicación para todas las versiones candidatas.

Selecciona Save. Selecciona Build with Parameters, conserva broken y selecciona Build. Espera a que termine la nueva ejecución numerada. Abre Console Output. Esta vez debes ver:

Pricing failures: 1
Stage "Publish" skipped due to earlier stage(s) marking the build as unstable
Finished: UNSTABLE

Abre Tests. Deben seguir apareciendo la misma prueba fallida y las tres pruebas superadas. La nueva ejecución no debe contener Release received. La tienda aún puede mostrar la versión incorrecta anterior: bloquear un nuevo intento no revierte automáticamente una publicación previa. A continuación la sustituirás por la versión candidata que funciona correctamente.

Si la ejecución informa de un error de sintaxis de Groovy, abre Configure de nuevo. Comprueba que la línea options añadida esté dentro de pipeline, justo debajo de agent any, con las llaves equilibradas. Corrígela, selecciona Save y vuelve a ejecutar broken. Un fallo de sintaxis por sí solo no completa este paso. Jenkins a veces muestra un aviso del publicador de Checks API; este curso local no utiliza un servicio Git alojado, por lo que ese aviso no sustituye al resultado real de la prueba.

Publica la versión candidata que funciona correctamente

En este paso demostrarás que el mismo Pipeline puede entregar una actualización correcta y conservar la experiencia normal del cliente. Empieza en la página del trabajo shop-update en Jenkins.

Selecciona Build with Parameters. Establece RELEASE en fixed y selecciona Build. Esto selecciona la versión candidata correcta proporcionada; no cambia el Pipeline que acabas de probar. Espera a que termine y abre Console Output de la nueva ejecución.

Pricing failures: 0
Release received
Finished: SUCCESS

Abre Tests. Las cuatro pruebas de precios deben superarse. Vuelve a la página de estado de esa ejecución y busca Build Artifacts. Descarga shop-release.tar.gz. Un artefacto es un archivo que Jenkins conserva para esta ejecución; este archivo comprimido contiene el programa de precios, los metadatos de la versión y la tarjeta de cuidados. El archivo también es el paquete real enviado a la tienda, no una copia reconstruida por separado.

Cambia a Gift Shop, selecciona el enlace de la marca para volver al inicio y actualiza la página. La colección ahora es Gifts to grow together. Abre Shop y comprueba tres kits de semillas: productos £32.40, envío £4.00, total £36.40. Dos cajas de pícnic deben seguir teniendo envío gratuito. Abre Delivery y Visit, descarga de nuevo la tarjeta de cuidados y confirma que esté completa.

Cesta correcta con el importe de los productos, el envío y el total correctos

La comprobación final vincula las ejecuciones reales fallida y correcta con el Pipeline guardado actualmente y con los bytes desplegados. Si editas el Pipeline después de estas ejecuciones, repite broken y después fixed para que ambos resultados correspondan a la versión que estás entregando. Conserva las ejecuciones anteriores y los recursos originales de la tienda; no se requiere escribir informes ni copiar la consola a un archivo.

Si has seleccionado broken de nuevo por error, deja el control de publicación activo y ejecuta fixed. Si Jenkins aún está ejecutando el trabajo, espera al resultado final de la ejecución numerada en lugar de lanzar más ejecuciones repetidamente. Una página de inicio correcta por sí sola no es suficiente: los precios de la cesta y la descarga forman parte del trabajo terminado.

Resumen

Has observado una prueba real de precios fallida, has visto por qué una ejecución inestable seguía publicando y has vinculado el resultado de las pruebas de Jenkins con un control de publicación. Después has usado el mismo Pipeline para entregar la versión candidata correcta y has comprobado los precios reales, el paquete archivado y las funciones normales de la tienda.