Prácticas recomendadas sobre Java

Mantener las aplicaciones actualizadas se ha vuelto importante y difícil. En este documento, se proporcionan algunos pasos básicos para que los desarrolladores de Java comiencen a utilizar las prácticas de DevOps. No es una lista exhaustiva. La mayoría de estas ideas provienen de los estudios de investigación y evaluación sobre DevOps de DORA, que proporcionan una descripción general más completa de las prácticas recomendadas. Otras fuentes son las siguientes: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations de Nicole Forsgren PhD, Jez Humble y Gene Kim; y Software Engineering at Google seleccionado por Titus Winters, Tom Manshreck y Hyrum Wright.

Antes de leer esta página, te recomendamos que leas: Configura un entorno de desarrollo de Java.

Las necesidades de cada organización de desarrollo son únicas, pero se puede construir un sistema básico mediante una de las siguientes tech stacks:

Ejemplo de tech stack 1 Ejemplo de tech stack 2
  • Cloud Source Repositories, GitHub o Bitbucket para el código fuente.
  • Whitesource RenovateBot para mantener actualizados los artefactos y las bibliotecas
  • Cloud Build para pruebas de unidades y envíos previos
  • Cloud Build para pruebas de integración
  • Cloud Build para la implementación
  • GitHub para el código fuente.
  • GitHub Dependabot para mantener actualizados los artefactos y las bibliotecas
  • Acciones de GitHub para pruebas de envío previo
  • Acciones de GitHub para pruebas de integración
  • Acciones de GitHub para la implementación

Un sistema sencillo compilado con estos componentes puede permitirte mejorar la calidad y el tiempo del ciclo. También te permite mantener fácilmente actualizado tu código con las correcciones de errores y actualizaciones de seguridad más recientes.

Control de versiones

La investigación (Página 17 Página 14 Página 31 y Página 60) descubrió que el control de versiones para el código fuente combinado con la automatización y las pruebas, se predice una mejor calidad y muchos otros beneficios.

GitHub, Gitlab y Bitbucket también son buenos hogares para tu código fuente.

Prueba automatizada

Las pruebas continuas pueden ser fundamentales para tu éxito con la mayoría de estas técnicas. Si deseas obtener ideas adicionales sobre prácticas recomendadas de prueba, consulta el capítulo Pruebas de confiabilidad del Libro de SRE y el Blog de pruebas de Google.

Los desarrolladores de Java se preocupan principalmente de las pruebas de unidades automatizadas y las pruebas de integración. JUnit, Prueba con Spring, Apache Maven Surefire y Pruebas de Gradle para Java son recursos útiles para los desarrolladores de Java.

Integración continua/automatización de la implementación

La integración continua y la automatización de la implementación impulsan los trabajos modernos de DevOps. Compila, prueba y, además, implementa.

  • Cloud Build [Guías de inicio rápido ][Específico de Java ][Implementación ][Activador] proporciona un sistema de compilación fácil de usar y de bajo costo o gratis (120 minutos de compilación por día) que se puede personalizar con facilidad para la mayoría de los trabajos.
  • Tekton es un proyecto de código abierto que te permite adaptar con facilidad las ideas de Cloud Build a tus sistemas.
  • Spinnaker es una plataforma de entrega continua de código abierto y múltiples nubes que te ayuda a lanzar cambios de software con alta velocidad y confianza. Te ayuda a administrar el proceso de lanzamiento y reversión de sistemas de software complejos.
  • Acciones de GitHub es una solución de terceros que te permite configurar pruebas y ejecutarlas con facilidad en GitHub.
  • También hay muchas otras soluciones, como GitLab, Circle CI y Travis CI.

Bibliotecas cliente de Cloud

Hay muchas formas de usar los servicios de Google, pero la forma preferida es seguir las instrucciones de la página Bibliotecas cliente de Cloud. Para Java, Libraries-BOM puede ayudar a garantizar que uses versiones compatibles de cada artefacto.

Si decides elegir tus propias versiones de bibliotecas cliente, es posible que se seleccione un artefacto no compatible. Esto se conoce como el problema de dependencia de diamante. Si aún debes elegir tus bibliotecas individuales, actualízalas una por una y pruébalas para ver si la actualización introdujo un error. Las versiones más recientes siempre se enumeran en esta página o puedes encontrarlas si buscas Maven-Central.

Mantén las dependencias actualizadas

Para protegerte contra actores maliciosos, es fundamental que mantengas tus dependencias actualizadas. Existen muchas herramientas de terceros que pueden ayudarte con esto:

Estas herramientas, cuando se configuran correctamente, te ayudan a mantener tus dependencias actualizadas. Cuando combinas pruebas automatizadas y, también, Integración continua/Implementación continua, el flujo se convierte en lo siguiente:

  • La automatización de dependencias sugiere un cambio en el control de origen.
  • El sistema de compilación continua compila y prueba el cambio.
  • Una persona revisa la propuesta y, si es aceptable, acepta el cambio, posiblemente junto con otros cambios.
  • Después de aceptar los cambios, se hace una propuesta al sistema de entrega continua para lanzar el código a producción. (O bien, se sigue tu proceso personalizado).

Usa un Java Runtime Environment (JRE) compatible

El JRE, un subconjunto de Java Development Kit, se encuentra sobre tu sistema operativo y proporciona el software y los recursos necesarios para ejecutar una aplicación de Java. La mayoría de los usuarios prefieren usar la versión de LTS más reciente en producción para que tengan acceso a actualizaciones, seguridad y correcciones de errores. Por lo general, es posible actualizar a un JRE más reciente, incluso si tu código se compila en un JDK anterior.

Si trabajas con varias versiones de JDK, SDKMAN! puede ayudarte a usar y administrar diferentes versiones de JDK.

Usa contenedores (clústeres de Anthos, Google Kubernetes Engine, Cloud Run)

Si usas contenedores de Docker con RenovateBot o DependaBot, el bot propone periódicamente actualizaciones a tu JRE y a tu JDK: deberás mantener el JDK y el JRE en la misma versión.

En la mayoría de las circunstancias, recomendamos usar Jib para alojar tus aplicaciones de Java en contenedores.

Si actualizas tu Dockerfile de forma manual, solo cambia el JRE a la versión más reciente y vuelve a compilarlo.

Usa Compute Engine

Esto suele ser muy específico de la aplicación. Recomendamos usar una secuencia de comandos de inicio. Para actualizar, debes actualizar la secuencia de comandos.

Entorno flexible de App Engine

Solo admite Java 8.

Entorno estándar de App Engine

Consulta Migra tu app de App Engine de Java 8 a Java 11.

Usa una versión de asistencia a largo plazo del kit de desarrollo de Java

El JDK es un conjunto de herramientas para desarrollar aplicaciones de Java. Las funciones nuevas de lenguaje están vinculadas a un JDK específico. Te recomendamos fijar tu uso a un JDK con asistencia a largo plazo y actualizarlo a la siguiente versión cuando sea adecuado para tu aplicación. Te recomendamos que uses la última versión secundaria de la versión principal fija de la asistencia a largo plazo.

La mayoría de los usuarios desearán mantener sincronizados el JDK y JRE. A veces, eso no es posible (por ejemplo, cuando el JDK ya no es compatible), y necesitas compilar con un JDK posterior y ejecutar en un JRE anterior.

Para hacer esto con Maven:

Establece el nivel de lenguaje en el que deseas codificar y el JRE de destino. Actualiza el archivo pom.xml de la siguiente manera (para Java 8): xml <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target>

Para actualizar a Java 11, debes cambiarlo a lo siguiente:

    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>

Si usas Gradle, actualiza el archivo build.gradle para Java 8 con el siguiente comando:

compileJava {
  sourceCompatibility = 1.8
  targetCompatibility = 1.8
}

O para Java 11:

compileJava {
  sourceCompatibility = 11
  targetCompatibility = 11
}

Ten en cuenta que, para Java 8 y las versiones anteriores, tenía un prefijo 1. (1.7 para Java 7, 1.8 para Java 8) que se descartó después de Java 8.