Estamos escribiendo un proyecto. Agregue SpringBoot y configure un proceso de CI: "Proyecto Java de la A a la Z"

Un artículo de una serie sobre la creación de un proyecto Java (los enlaces a otros materiales se encuentran al final). Su objetivo es analizar tecnologías clave y el resultado es escribir un bot de Telegram. Saludos, queridos lectores. Como se describió en la parte anterior , iremos según lo planeado. Ya hemos creado un proyecto y es hora de llenarlo de código. Ahora todos los problemas se agregarán como confirmaciones separadas. Describiré todo lo que sea necesario aquí. Si me olvido de algo o no lo describo con suficiente claridad, pregunta en los comentarios, intentaré responderte.

Escribimos JRTB-0M

En esta tarea necesitamos agregar un marco SpringBoot vacío para trabajos futuros. Haremos esto de la misma manera que lo hicimos en el artículo sobre SpringBoot + Flyway . Descargue el proyecto , ábralo en IDEA y cree una nueva rama llamada JRTB-0 . Describí cómo hacer esto a través de una idea aquí . Esto nos facilitará el seguimiento del trabajo en el futuro. ¿Sabías ya que ya no existe una sucursal master ? Ahora se llama neutralmente principal . Entonces nos acostumbramos. Aunque, para ser sinceros, siempre podremos cambiarle el nombre de nuevo a master. Vamos a Spring Initializr y creamos un framework SpringBoot para nuestro bot. Por el momento, la versión más joven de Boot Sprint que se ofrece es la 2.3.7, vamos a tomarla. Describiré las siguientes configuraciones por separado:

• Proyecto: Proyecto Maven : ya hemos hablado de Maven aquí y aquí . Por lo tanto, describiré adicionalmente solo lo que no revelé en artículos anteriores. Si existen tales “puntos blancos”, por supuesto)
• Idioma: Java : aquí todo está claro. Si lo deseamos, podemos reescribir este asunto en Kotlin. Acabo de comprarme un libro Kotlin en acción, aprenderemos Kotlin juntos))
• Spring Boot: 2.3.7 : tomamos la versión más pequeña ofrecida para eliminar cualquier problema. Esta ya es una versión completamente moderna del maletero.

Metadatos del proyecto:

• Grupo: com.github.javarushcommunity : aquí seleccionamos el dominio en el que está alojado nuestro grupo de repositorios.
• Artefacto: javarush-telegrambot : descripción máxima del proyecto.
• Nombre: Javarush TelegramBot : lo escribiremos completo aquí.
• Descripción: Bot de Telegram para Javarush de comunidad en comunidad : aquí hay una descripción más detallada del proyecto.
• Nombre del paquete: com.github.javarushcommunity.jrtb : aquí ya puede utilizar una abreviatura para el nombre del proyecto. Ahora el proyecto comenzará con este paquete. ¿Porqué tantos? De modo que cuando agreguemos otros proyectos al classpath, estarán en paquetes diferentes. Cada uno a su manera. Esto es importante para mantener los principios de programación orientada a objetos.
• Embalaje: El tarro es nuestro estándar)
• Java: 11 : estaremos un paso por delante. No creo que utilice innovaciones después del octavo Java, pero déjalo así. No pide comida)... esta decisión nos dará un pequeño huevo de Pascua en el futuro)

No agregaremos ninguna dependencia por ahora. No necesitamos esto para esta tarea. Habiendo completado todo esto, obtenemos (aquí hay un enlace al proyecto generado): Habiendo completado, haga clic en GENERAR y agregue todos los elementos internos del archivo a nuestro proyecto. Agregue archivos al proyecto. Como resultado, tenemos una aplicación. Para comprobar si está ensamblado, vaya a la terminal y escriba: $ mvn clean package. Si tiene lo mismo que aquí, todo está bien: el proyecto está ensamblado y el jarnik ya está listo en la carpeta de destino. En este punto, la tarea dentro de la descripción está lista. Es simple, ¿verdad? Por lo tanto, nos comprometemos y enviamos a nuestra rama: agregamos el nombre de nuestra tarea al comienzo de la descripción de la confirmación, para que luego quede claro en el marco de qué tarea se realizó el trabajo. Haga clic en Confirmar y enviar ... Una vez más revisamos y comprobamos qué es exactamente lo que queremos enviar desde el repositorio local al remoto y, asegurándonos de que todo está bien, hacemos clic en Enviar . ¿Cuál es nuestro siguiente paso? De acuerdo con todas las reglas (que se pueden leer en este artículo , en la parte sobre el flujo de GitHub), debes crear una solicitud de extracción para la rama principal y esperar a que alguien del equipo revise el código. Como estoy solo, crearé formalmente una solicitud de extracción y revisaré todo nuevamente. Voy a la página del repositorio y Github ya sabe que tenemos una adición y se ofrece a crear una solicitud de extracción: No hay obstáculos para los patriotas (c): la creamos como se sugiere. Establecemos la misma etiqueta, proyecto que en la tarea en la que estamos trabajando y completamos la descripción: Haga clic en Crear solicitud de extracción .

Configurar el proceso de CI

Nos dirigimos al pull request creado: abajo vemos que no tenemos configurada la Integración Continua (en adelante - CI). Bueno, no está configurado, ¿y qué? ¿Por qué necesitamos CI? ¿Qué es CI de todos modos? Esta es aproximadamente la lista de preguntas que deberían preocuparnos en este momento. En general, la CI es un proceso continuo de fusionar código en una base de código común y ejecutar una compilación del proyecto antes de eso. La llamada construcción (del inglés build). Cada vez que construimos un proyecto, nos aseguramos de que el proyecto haya sido compilado, que todas sus pruebas hayan pasado exitosamente y, además, después de compilar el proyecto, puede agregar pruebas automáticas de los evaluadores al CI que se ejecutan en esta compilación específica. De esta manera, tenemos más confianza en que los nuevos cambios funcionan como esperamos y no interrumpen la funcionalidad anterior. CI también es bueno porque se inicia automáticamente después de actualizar el código base. Es decir, introdujimos nuestros cambios en la rama y comenzó el proceso: ensamblaje, pruebas, pruebas automáticas y otros pasos. Si alguno de estos pasos falla, la compilación se considera rota y no se puede fusionar con la rama principal. Esto es exactamente lo que haremos ahora: agregaremos GitHub Actions, que ejecutarán nuestro código después del envío. GitHub Actions encaja perfectamente en nuestro GitHub Flow, por lo que lo usaremos para automatizar nuestro trabajo. Esta herramienta es muy poderosa y grande, pero por ahora solo la usaremos para ejecutar la compilación y verificar que esté ensamblada según sea necesario. Para habilitarlo, busque el botón Acciones en la página del repositorio y sígalo: Busque el flujo de trabajo de integración continua que necesitamos: haga clic en Configurar este flujo de trabajo. A continuación, nos ofrecen utilizar su plantilla: estamos completamente de acuerdo, aclaremos todo un poco:

# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven

name: Java CI with Maven

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build with Maven
      run: mvn -B package --file pom.xml

Esto indica que se llama a GitHub Action en dos casos:

1. Cuando se realiza un empujón a la rama principal.
2. Cuando se crea una solicitud de extracción en la rama principal.

La sección de trabajos describe los pasos que se realizarán. Sólo nos queda un paso: construir. Muestra que nuestro proyecto se iniciará en Ubuntu con el comando mvn -B paquete --file pom.xml . Esto es exactamente lo que hicimos localmente. Si quieres cambiar algo aquí, por favor. Usaré esta plantilla, será suficiente para mí. Hago clic en Iniciar confirmación , selecciono crear una nueva rama para configurar el proceso y luego Proponer nuevo archivo . Pero el proceso de construcción fracasó... Como puede ver, fallando después de 14 segundos: compilación. Parece que algo pasó: pasemos al montaje y miremos los detalles: Dice que no encontré tal recuerdo. ¿Por qué? ¡Ahhh, exactamente, exactamente! Porque creamos cambios en la rama maestra, pero nuestra tarea aún no ha llegado allí. Y es por eso que no encontró la memoria... Por lo tanto, ahora hacemos lo siguiente: fusionamos estos datos en el maestro, luego fusionamos la rama principal en JRTB-0, y luego todo debería ir bien. En una solicitud de extracción con cambios en las acciones de github, haga clic en Fusionar solicitud de extracción : y repita Confirmar fusión . A continuación, Github nos solicita que eliminemos la rama en la que trabajamos. No rechazamos ni eliminamos: A continuación, no encontré en la solicitud de extracción de SpringBoot cómo extraer cambios de la rama principal del sitio web, por lo que lo haremos manualmente a través de IDEA.

Paso 1: actualice la rama maestra al repositorio local.

La idea es ir a la rama master, presionar ctrl + t y actualizar la rama master:

Paso 2: fusionar los cambios de la rama maestra con la rama JRTB-0.

Vayamos a JRTB-0 y fusionemos el principal con él.

Paso 3: impulsar los cambios.

Presione Ctrl + Shift + K y confirme la pulsación. ¡Ahora estamos esperando que pase la compilación y será verde!)) Pero vuelve a ser rojo. ¿Qué es? Entramos en los registros de acciones y vemos que no tenemos sincronización en las versiones de Java. En GitHubActions es 8, pero usamos 11: Ahora hay dos opciones: corregir las acciones o bajar la versión a la octava. La primera opción, me parece, es mejor y más correcta. Estamos realizando cambios en una confirmación separada: no trabajaremos con Java 8, sino con Java 11. Y después de eso, finalmente todo funcionó para nosotros y pudimos configurar nuestro proceso de CI para el proyecto. Estas cosas deben configurarse en la etapa inicial, para que no tengas que preocuparte por ello más adelante. Ahora puedes ver que la compilación ha pasado y puedes fusionarte sin miedo:

Configurar el trabajo con sucursales en el repositorio.

También puede configurar cosas en el repositorio como reglas cuando trabaje con sucursales. Quiero que la rama principal no pueda ser enviada directamente, sino solo a través de solicitudes de extracción, y quiero que sea imposible fusionar una solicitud de extracción si la compilación falla (es decir, si GitHub Actions falló en algún paso). Para hacer esto, busque el botón Configuración y seleccione Ramas : por el momento no hay reglas para las ramas, así que agreguemos una nueva a través del botón Agregar regla : aquí hay muchas configuraciones y todos pueden hacer algo que se adapte a sus necesidades. necesidades. Para que la compilación se realice correctamente en la solicitud de extracción antes de la fusión, agregue una casilla de verificación para Requerir que se aprueben las comprobaciones de estado antes de la fusión y seleccione el estado que necesitamos: compilación. Eso es suficiente por ahora: luego podrás actualizar este volante y ver qué más quieres. Haga clic en Crear para crear este volante. A continuación, si volvemos a nuestra solicitud de extracción, podemos ver que nuestra verificación ahora está marcada como obligatoria: revisemos la página de nuestro proyecto, que muestra todos los estados de las tareas: puede ver inmediatamente en qué tarea se está trabajando. Además, el trabajo ya se ha realizado y la tarea se encuentra en estado de revisión de código.

Cerrando JRTB-0

Ahora que hemos preparado una solicitud de extracción y hemos creado un CI para ella, debemos completar la última etapa: cerrar la tarea, moverla al estado correcto y observar los cambios en nuestro proyecto en el tablero. Nuestra solicitud de extracción está lista para fusionarse con la maestra. En la solicitud de extracción, haga clic en el botón Fusionar solicitud de extracción : después de una combinación exitosa, puede eliminarla y, por lo general, lo hace. No haré esto para que le resulte más fácil ver los cambios entre ramas/confirmaciones. Tan pronto como se fusiona una solicitud de extracción, automáticamente se realiza en nuestro tablero de proyecto: El último paso es cerrar el problema (problema) con un enlace a la solicitud de extracción en la que estaba: Este problema se realiza automáticamente en el junta. ¡Se ha hecho el comienzo, la primera tarea está hecha!

conclusiones

Parecería que ya hemos comenzado a trabajar y escribir código, pero aún se necesitan configuraciones. Sí, lleva tiempo, pero dará cien veces más frutos cuando el proyecto se vuelva más grande y complejo y necesites garantías de que no arruinarás todo con un solo compromiso. La solicitud de extracción donde sucede todo esto está disponible aquí . Quizás, cuando leas, ya esté cerrado. No tiene miedo: toda la información necesaria se almacenará a través del enlace. Gracias a todos por leer, nos vemos pronto. ¡Además!

Al principio de este artículo encontrará una lista de todos los materiales de la serie.