Tutorial de entrega continua: creación de una canalización de entrega continua con Jenkins

Entrega continua:

La entrega continua es un proceso en el que los cambios de código se crean, prueban y preparan automáticamente para su lanzamiento a producción.Espero que hayas disfrutado de mi Aquí, hablaré de los siguientes temas:

• ¿Qué es la entrega continua?
• Tipos de pruebas de software
• Diferencia entre integración, entrega e implementación continuas
• ¿Cuál es la necesidad de una entrega continua?
• Práctica con Jenkins y Tomcat

Comprendamos rápidamente cómo funciona la Entrega continua.

¿Qué es la entrega continua?

Es un proceso en el que crea software de tal manera que puede lanzarse a producción en cualquier momento.Considere el diagrama a continuación:

Déjame explicarte el diagrama anterior:

• Los scripts de compilación automatizados detectarán cambios en la administración de código fuente (SCM) como Git.
• Una vez que se detecta el cambio, el código fuente se implementará en un servidor de compilación dedicado para asegurarse de que la compilación no falle y de que todas las clases de prueba y las pruebas de integración funcionen correctamente.
• Luego, la aplicación de compilación se implementa en los servidores de prueba (servidores de preproducción) para la Prueba de aceptación del usuario (UAT).
• Finalmente, la aplicación se implementa manualmente en los servidores de producción para su lanzamiento.

Antes de continuar, será justo que le explique los diferentes tipos de pruebas.

Tipos de pruebas de software:

En términos generales, hay dos tipos de pruebas:

• Prueba de caja negra: Es una técnica de prueba que ignora el mecanismo interno del sistema y se enfoca en la salida generada contra cualquier entrada y ejecución del sistema. También se llama prueba funcional. Básicamente se utiliza para validar el software.
• Prueba de caja blanca: es una técnica de prueba que tiene en cuenta el mecanismo interno de un sistema. También se denomina prueba estructural y prueba de caja de vidrio. Básicamente se utiliza para verificar el software.

Prueba de caja blanca:

Hay dos tipos de pruebas que se incluyen en esta categoría.

• Examen de la unidad: Es la prueba de una unidad individual o grupo de unidades relacionadas. A menudo, el programador lo hace para probar que la unidad que ha implementado está produciendo la salida esperada contra la entrada dada.
• Pruebas de integración: Es un tipo de prueba en la que un grupo de componentes secombinado para producir la salida. Además, la interacción entre el software y el hardware se prueba si los componentes del software y del hardware tienen alguna relación. Puede caer tanto en la prueba de caja blanca como en la prueba de caja negra.

Prueba de caja negra:

Hay varias pruebas que se incluyen en esta categoría. Me enfocaré enunos pocos, que es importante que conozca para comprender este blog:

• Pruebas funcionales / de aceptación: Asegura que funcione la funcionalidad especificada requerida en los requisitos del sistema. Se hace para asegurarse de que el producto entregado cumpla con los requisitos y funcione como esperaba el cliente.
• Prueba del sistema: Garantiza que al colocar el software en diferentes entornos (por ejemplo, sistemas operativos) aún funcione.
• Pruebas de estrés: Evalúa cómo se comporta el sistema en condiciones desfavorables.
• Prueba Beta: Lo hacen los usuarios finales, un equipo externo al desarrollo o la liberación pública de una versión previa completa del producto, que se conoce comobetaversión. El objetivo de las pruebas beta es cubrir errores inesperados.

Ahora es el momento adecuado para explicar la diferencia entre integración continua, entrega e implementación.

Diferencias entre integración, entrega e implementación continuas:

El contenido visual llega al cerebro de una persona de una manera más rápida y comprensible que la información textual. Entonces, voy a comenzar con un diagrama que explica claramente la diferencia:

En la integración continua, cada confirmación de código se compila y se prueba, pero no está en condiciones de ser liberada. Me refiero a que la aplicación de compilación no se implementa automáticamente en los servidores de prueba para validarla utilizando diferentes tipos de pruebas de Blackbox como: Pruebas de aceptación de usuario (UAT).

En Continuous Delivery, la aplicación se implementa continuamente en los servidores de prueba para UAT. O puede decir que la aplicación está lista para ser lanzada a producción en cualquier momento. Entonces, obviamente la Integración Continua es necesaria para la Entrega Continua.

Continuous Deployment es el siguiente paso después de Continuous Delivery, donde no solo está creando un paquete implementable, sino que en realidad lo está implementando de forma automatizada.

Permítanme resumir las diferencias usando una tabla:

En términos simples, la integración continua es parte tanto de la entrega continua como de la implementación continua. Y la implementación continua es como la entrega continua, excepto que los lanzamientos ocurren automáticamente.

Aprenda a crear canalizaciones de CI / CD con Jenkins en la nube

Pero la pregunta es si la Integración Continua es suficiente.

¿Por qué necesitamos una entrega continua?

Entendamos esto con un ejemplo.

Imagina que hay 80 desarrolladores trabajando en un gran proyecto. Están utilizando canalizaciones de integración continua para facilitar las compilaciones automatizadas. Sabemos que la compilación también incluye pruebas unitarias. Un día decidieron implementar la última versión que había pasado las pruebas unitarias en un entorno de prueba.

Este debe ser un enfoque de implementación prolongado pero controlado que llevaron a cabo sus especialistas en medio ambiente. Sin embargo, el sistema no pareció funcionar.

¿Cuál podría ser la causa obvia del fracaso?

Bueno, la primera razón por la que la mayoría de la gente pensará es que hay algún problema con la configuración. Como la mayoría de la gente, incluso ellos lo pensaban.Pasaron mucho tiempo tratando de encontrar qué estaba mal en la configuración del entorno, pero no pudieron encontrar el problema.

diferencia de Java entre hashmap y hashtable

Un desarrollador perspicaz adoptó un enfoque inteligente:

Luego, uno de los desarrolladores senior probó la aplicación en su máquina de desarrollo. Allí tampoco funcionó.

Retrocedió a través de versiones anteriores y anteriores hasta que descubrió que el sistema había dejado de funcionar tres semanas antes. Un pequeño y oscuro error había impedido que el sistema se iniciara correctamente. Aunque, el proyecto tuvo una buena cobertura de prueba unitaria.A pesar de esto, 80 desarrolladores, que generalmente solo ejecutaron las pruebas en lugar de la aplicación en sí, no vieron el problema durante tres semanas.

Planteamiento del problema:

Sin ejecutar pruebas de aceptación en un entorno de producción, no saben nada acerca de si la aplicación cumple con las especificaciones del cliente, ni si se puede implementar y sobrevivir en el mundo real. Si desean recibir comentarios oportunos sobre estos temas, deben ampliar el alcance de su proceso de integración continua.

Permítanme resumir las lecciones aprendidas observando los problemas anteriores:

• Las pruebas unitarias solo prueban la perspectiva de un desarrollador de la solución a un problema. Tienen solo una capacidad limitada para demostrar que la aplicación hace lo que se supone que debe hacer desde la perspectiva del usuario. No son suficientes paraidentificar los problemas funcionales reales.
• La implementación de la aplicación en el entorno de prueba es un proceso complejo, intensivo manualmente que era bastante propenso a errores.Esto significaba que cada intento de implementación era un nuevo experimento: un proceso manual propenso a errores.

Solución: canalización de entrega continua (prueba de aceptación automatizada):

Llevaron la Integración Continua (Entrega Continua) al siguiente paso e introdujeron un par de Pruebas de Aceptación simples y automatizadas que demostraron que la aplicación se ejecutaba y podía realizar su función más fundamental.La mayoría de las pruebas que se ejecutan durante la etapa de prueba de aceptación son pruebas de aceptación funcional.

Básicamente, crearon una canalización de entrega continua para asegurarse de que la aplicación se implemente sin problemas en el entorno de producción, asegurándose de que la aplicación funcione bien cuando se implementa en el servidor de prueba, que es una réplica del servidor de producción.

Suficiente de teoría, ahora le mostraré cómo crear una canalización de entrega continua usando Jenkins.

Canalización de entrega continua con Jenkins:

Aquí usaré Jenkins para crear un canal de entrega continua, que incluirá las siguientes tareas:

Pasos involucrados en la demostración:

• Obteniendo el código de GitHub
• Compilando el código fuente
• Prueba unitaria y generación de informes de prueba JUnit
• Empaquetar la aplicación en un archivo WAR e implementarla en el servidor Tomcat

Prerrequisitos:

• Máquina CentOS 7
• Jenkins 2.121.1
• Estibador
• Tomcat 7

Paso - 1 Compilación del código fuente:

Comencemos por crear primero un proyecto de estilo libre en Jenkins. Considere la siguiente captura de pantalla:

Dé un nombre a su proyecto y seleccione Proyecto Freestyle:

Cuando se desplaza hacia abajo, encontrará una opción para agregar un repositorio de código fuente, seleccione git y agregue la URL del repositorio, en ese repositorio hay un pom.xml fino que usaremos para construir nuestro proyecto. Considere la siguiente captura de pantalla:

Ahora agregaremos un disparador de compilación. Elija la opción de encuesta SCM, básicamente, configuraremos Jenkins para sondear el repositorio de GitHub cada 5 minutos en busca de cambios en el código. Considere la siguiente captura de pantalla:

Antes de continuar, permítame darle una pequeña introducción al ciclo de compilación de Maven.

Cada uno de los ciclos de vida de la compilación se define mediante una lista diferente de fases de compilación, en la que una fase de compilación representa una etapa del ciclo de vida.

A continuación se muestra la lista de fases de construcción:

• validar: validar que el proyecto es correcto y que toda la información necesaria está disponible
• compilar: compila el código fuente del proyecto
• prueba: prueba el código fuente compilado utilizando un marco de prueba unitario adecuado. Estas pruebas no deberían requerir que el código esté empaquetado o implementado
• paquete: tome el código compilado y empaquelo en su formato distribuible, como un JAR.
• verificar: ejecute cualquier verificación de los resultados de las pruebas de integración para garantizar que se cumplan los criterios de calidad
• instalar: instala el paquete en el repositorio local, para usarlo como una dependencia en otros proyectos localmente
• implementar: hecho en el entorno de compilación, copia el paquete final en el repositorio remoto para compartirlo con otros desarrolladores y proyectos.

Puedo ejecutar el siguiente comando para compilar el código fuente, realizar pruebas unitarias e incluso empaquetar la aplicación en un archivo war:

paquete limpio mvn

También puede dividir su trabajo de construcción en varios pasos de construcción. Esto facilita la organización de compilaciones en etapas limpias y separadas.

Entonces comenzaremos compilando el código fuente. En la pestaña de compilación, haga clic en invocar objetivos maven de nivel superior y escriba el siguiente comando:

compilar

Considere la siguiente captura de pantalla:

Esto extraerá el código fuente del repositorio de GitHub y también lo compilará (fase de compilación de Maven).

Haga clic en Guardar y ejecute el proyecto.

Ahora, haga clic en la salida de la consola para ver el resultado.

Paso - Prueba unitaria 2:

Ahora crearemos un proyecto de estilo libre más para las pruebas unitarias.

Agregue la misma URL del repositorio en la pestaña de administración del código fuente, como hicimos en el trabajo anterior.

Ahora, en la pestaña 'Buid Trigger', haga clic en 'construir después de que se hayan creado otros proyectos'. Allí escriba el nombre del proyecto anterior donde estamos compilando el código fuente, y puede seleccionar cualquiera de las siguientes opciones:

• Activar solo si la construcción es estable
• Activar incluso si la construcción es inestable
• Activar incluso si la compilación falla

Creo que las opciones anteriores se explican por sí mismas, así que seleccione cualquiera. Considere la siguiente captura de pantalla:

En la pestaña Construir, haga clic en invocar objetivos maven de nivel superior y use el siguiente comando:

prueba

Jenkins también hace un gran trabajo al ayudarlo a mostrar los resultados de sus pruebas y las tendencias de los resultados de las pruebas.

El estándar de facto para los informes de pruebas en el mundo Java es un formato XML utilizado por JUnit. Este formato también lo utilizan muchas otras herramientas de prueba de Java, como TestNG, Spock y Easyb. Jenkins entiende este formato, por lo que si su compilación produce resultados de prueba JUnit XML, Jenkins puede generar buenos informes de prueba gráficos y estadísticas sobre los resultados de prueba a lo largo del tiempo, y también le permite ver los detalles de cualquier falla de prueba. Jenkins también realiza un seguimiento del tiempo que tardan en ejecutarse las pruebas, tanto a nivel mundial como por prueba; esto puede resultar útil si necesita rastrear problemas de rendimiento.

Entonces, lo siguiente que debemos hacer es lograr que Jenkins controle nuestras pruebas unitarias.

Vaya a la sección Acciones posteriores a la compilación y marque la casilla de verificación 'Publicar informe de resultados de la prueba JUnit'. Cuando Maven ejecuta pruebas unitarias en un proyecto, genera automáticamente los informes de prueba XML en un directorio llamado surefire-reports. Por lo tanto, ingrese “** / target / surefire-reports / *. Xml” en el campo “Test report XMLs”. Los dos asteriscos al comienzo de la ruta (“**”) son una buena práctica para hacer que la configuración sea un poco más sólida: permiten que Jenkins encuentre el directorio de destino sin importar cómo hayamos configurado Jenkins para verificar el código fuente.

** / target / surefire-reports / *. xml

Vuelva a guardarlo y haga clic en Construir ahora.

Ahora, el informe JUnit está escrito en / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

En el panel de Jenkinstambién puede notar los resultados de la prueba:

Paso - 3 Crear un archivo WAR e implementarlo en el servidor Tomcat:

Ahora, el siguiente paso es empaquetar nuestra aplicación en un archivo WAR e implementarlo en el servidor Tomcat para la prueba de aceptación del usuario.

Cree un proyecto de estilo libre más y agregue la URL del repositorio de código fuente.

Luego, en la pestaña de activación de compilación, seleccione compilar cuando se compilen otros proyectos, considere la siguiente captura de pantalla:

Básicamente, después del trabajo de prueba, la fase de implementación comenzará automáticamente.

En la pestaña de compilación, seleccione script de shell. Escriba el siguiente comando para empaquetar la aplicación en un archivo WAR:

paquete mvn

El siguiente paso es implementar este archivo WAR en Tomcatservidor. En la pestaña 'Acciones posteriores a la construcción', seleccione implementar war / ear en un contenedor. Aquí, proporcione la ruta al archivo war y la ruta del contexto. Considere la siguiente captura de pantalla:

Seleccione las credenciales de Tomcat y observe la captura de pantalla anterior. Además, debe proporcionar la URL de su servidor Tomcat.

Para agregar credenciales en Jenkins, haga clic en la opción de credenciales en el panel de Jenkins.

Haga clic en Sistema y seleccione credenciales globales.

diferencia entre javascript y jquery

Luego, encontrará una opción para agregar las credenciales. Haga clic en él y agregue credenciales.

Agregue las credenciales de Tomcat, considere la siguiente captura de pantalla.

Haga clic en Aceptar.

Ahora, en la configuración de su proyecto, agregue las credenciales de tomcat que ha insertado en el paso anterior.

Haga clic en Guardar y luego seleccione Construir ahora.

Vaya a su URL de tomcat, con la ruta de contexto, en mi caso es http: // localhost: 8081. Ahora agregue la ruta de contexto al final, considere la siguiente captura de pantalla:

Enlace - http: // localhost: 8081 / gof

Espero que hayas entendido el significado de la ruta de contexto.

Ahora cree una vista de canalización, considere la siguiente captura de pantalla:

Haga clic en el icono más para crear una nueva vista.

Configure la canalización de la manera que desee, considere la siguiente captura de pantalla:

No cambié nada más que seleccionar el trabajo inicial. Entonces mi canalización comenzará desde la compilación. Según la forma en que he configurado otros trabajos, después de la compilación, se realizarán las pruebas y la implementación.

Finalmente, puede probar la canalización haciendo clic en EJECUTAR. Después de cada cinco minutos, si hay un cambio en el código fuente, se ejecutará toda la canalización.

Entonces, podemos implementar continuamente nuestra aplicación en el servidor de prueba para la prueba de aceptación del usuario (UAT).

Espero que haya disfrutado leyendo esta publicación sobre Entrega continua. Si tiene alguna duda, no dude en ponerla en la sección de comentarios a continuación y le responderé lo antes posible.

Para construir canalizaciones de CI / CD, necesita dominar una amplia variedad de habilidades Domine las habilidades de DevOps necesarias ahora