Una vez que hemos desacoplado la ejecución de una aplicación de nuestro equipo y su entorno desplegándola en un contenedor, el siguiente paso es independizar también el proceso de compilación y construcción. El objetivo es evitar también problemas de configuraciones y dependencias relacionadas con el entorno de desarrollo, moviendo la responsabilidad a un proceso automatizado. De esta forma nos acercarnos más a un entorno de producción. Enfoque de partida El Dockerfile con el que hemos trabajado previamente incluye lo mínimo para desplegar el JAR: ...

Hoy día usamos la palabra bug de forma cotidiana para referirnos a cualquier error de software. Pero lo curioso es que este término, tan ligado a la informática moderna, nació de un fallo completamente literal. En el año 1947, un equipo de ingenieros trabajaba con el ordenador electromecánico Harvard Mark II. Durante una sesión de diagnóstico, el sistema empezó a comportarse de forma errática. Tras investigar el problema, encontraron la causa: una polilla atrapada en uno de los relés del equipo, impidiendo su correcto funcionamiento. ...

El principio de responsabilidad única es uno de los principios SOLID. Defiende los beneficios de que clases y funciones tengan una responsabilidad clara y específica, de forma que solo se tengan que modificar por un motivo. Aplicándolo conseguimos que nuestro código sea más claro y mantenible. El problema real Seguro que en algún momento de tu vida como desarrollador te has cruzado con clases que validan datos, acceden a base de datos, construyen respuestas, escriben logs, aplican lógica de negocio… todo en un mismo sitio. ...

Alrededor de la programación hay una serie de tareas menos agradecidas y poco atractivas para la mayoría de los desarrolladores: el análisis, la documentación… los tests y las pruebas. Con cada nuevo evolutivo solemos lanzarnos directamente al teclado, abrir nuestro IDE y empezar a picar código, cuando muchas veces lo más efectivo a largo plazo es comenzar con papel y bolígrafo, desgranando qué queremos hacer realmente. Con las pruebas y los tests sucede algo similar. Durante el desarrollo vamos lanzando comprobaciones manuales y, cuando vemos que todo más o menos funciona, lo damos por válido. Puede que incluso documentemos alguna de ellas, pero suele percibirse como otra tarea pesada que no siempre motiva y que intentamos quitarnos de encima cuanto antes. ...

Hasta ahora, hemos creado una aplicación Hello World con Spring Boot, la hemos compilado con Maven y la hemos ejecutado correctamente en nuestro equipo. Sin embargo, ejecutar una aplicación en local es solo el primer paso. En cuanto queremos compartirla, desplegarla en un servidor o moverla entre distintos entornos (desarrollo, pruebas, producción), empiezan a aparecer los problemas clásicos: versiones diferentes de Java, dependencias que no coinciden, configuraciones específicas de la máquina o incluso sistemas operativos diferentes. ...