El documento habla sobre integración continua con Jenkins. Explica que Jenkins es un software que orquesta el proceso de integración continua automatizando la compilación del proyecto, aplicando controles de calidad, publicando en Nexus y realizando tags en Git. También describe conceptos como SNAPSHOT, RELEASE, pruebas unitarias, cobertura y SonarQube para análisis estático de código.

1. Integración Continua con Jenkins
Introducción - 1

2. Antonio Ramón Molina Milla
Arquitecto
Integración de Sistemas [ARIS]

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

5. ¿Jenkins?
Introducción - 5

6. ¿Jenkins?
Introducción - 6

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

11. Cobertura
Introducción - 11

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:

13. Sonarsource
VB.NET
Introducción - 13
PYTHON
PHP JavaScript

14. NullPointerExcepcion
Introducción - 14

15. IF/ELSE idénticos
Introducción - 15

16. Devolución del mismo valor
Introducción - 16

17. Recurso no cerrado tras su uso
Introducción - 17

18. Integrantes principales perfiles
Introducción - 18
Desarrolladores Quality Assurance Sistemas

19. Sistemas dedicados
Introducción - 19
Jenkins
Nexus
Sonar
GIT

20. docker + swarm
Sistemas dockerizados
Introducción - 20
Serv1 Serv2
Sonar Git Nexus
Jenkins 1 Jenkins 2

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

23. Introducción - 23
www.commitea.es
armolinamilla@gmail.com
@commiteatv
www.linkedin.com/in/armolinamilla
web
email
Twitter
Linkedin
Contacto