3. ¿Integración Contínua?
[Buena] práctica de desarrollo software donde los miembros de un
proyecto integran su trabajo frecuentemente y de forma automática
favoreciendo la detección de fallos en las fases más tempranas de
desarrollo.
Cada integración se verifica con un build SNAPSHOT automático (que
incluye la ejecución de pruebas) para detectar errores de integración
tan pronto como sea posible.
Si la verificación es correcta el SNAPSHOT puede convertirse en
RELEASE para avanzar por los distintos entornos de la empresa.
Introducción - 3
4. ¿Jenkins?
Es el software encargado de orquestar el proceso de Integración
contínua.
Está basado en Java y es ampliable mediante plugins:
- SonarQube
- Nexus
- Maven
- Git
Sus funciones principales son:
- Compilar el proyecto
- Aplicar el control de calidad basándose en los umbrales de
Release o Snapshot.
- Publicar en Nexus el compilado (.jar, .war, etc).
- Realizar los tags necesarios en GIT.
Introducción - 4
7. SNAPSHOT y RELEASE
SNAPSHOT: Dentro de Maven una instantánea es una versión de un
artefacto que está en desarrollo. El código puede ser modificado y
vuelto a compilar bajo el mismo nombre.
Umbral de pruebas más permisivo.
RELEASE: Versión inmutable originada por un SNAPSHOT.
Umbral de pruebas más estricto.
Dentro de Nexus existirán dos repositorios para garantizar que no se
mezclen los dos tipos de versiones y la persistencia de las Releases.
Introducción - 7
8. TDD
Test-Driven Development
Primero diseñamos las pruebas unitarias y posteriormente se
desarrolla el código fuente necesario para superarlas. Una vez se han
superado se simplifica el código y se refactoriza el código.
1. Se define una funcionalidad.
2. Se escoge el criterio de aceptación más simple y se traduce en
una prueba unitaria con resultado fallo.
3. Se escribe el código que hace pasar la prueba.
4. Se ejecutan todas las pruebas automatizadas.
5. Se refactoriza y se limpia el código.
Introducción - 8
9. Pruebas
Unitarias: Probar cada uno de los métodos del código de forma
aislada. Simulando la entrada de datos y verificando la salida obtenida
con la esperada. Usaremos: JUnit + Mockito + PowerMock.
Regresivas: Verificar que la interacción entre los métodos es correcta.
Estas pruebas son dependientes del entorno en el que se ejecutan y
suelen lanzarse de forma manual.
Integración, estrés, i18N, etc.
Introducción - 9
10. Cobertura
La cobertura mide el porcentaje de código que es ejecutado dentro de
alguna de nuestras pruebas unitarias.
No tiene sentido llegar a un 100% de cobertura. Una buena práctica
sería pedir el 60% y ajustar en los componentes que sean necesarios
incluso desactivar este tipo de análisis en las librerías de terceros.
Introducción - 10
12. Sonarqube
Aplicación de software libre para la evaluación de código estático
basado en Checkstyle, PMD o FindBugs.
Introducción - 12
Actualmente existen unas 495
reglas para Java.
Que permiten verificar los
siguientes puntos en nuestro
código:
21. Entornos
- Desarrollo: Normalmente la máquina del desarrollador dónde suele tener facilidad para debugar el código
desarrollado con acceso a los recursos en local y facilitar las pruebas unitarias.
- Preproducción o integración: Entorno donde los nuevos desarrollos conviven con el resto de la aplicación.
Es interesante que exista una volcado de datos ofuscados de producción para poder realizar pruebas
regresivas y de integración.
- Producción: Entorno en el que desplegamos nuestro código probado y validado con anterioridad para
mantener un alto nivel de calidad de la aplicación.
Introducción - 21
22. Dudas
Flujo de desarrollo:
Un equipo de desarrolladores planea generar un backend basado en
microservicios para nutrir una página web y una posible futura
aplicación móvil.
Introducción - 22
![Antonio Ramón Molina Milla
Arquitecto
Integración de Sistemas [ARIS]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)