Este documento describe las prácticas de integración y entrega continua, incluyendo sus beneficios como la detección rápida de errores y la mejora de la productividad. También discute los retos como la estructuración de proyectos para incluir tests y la capacidad de despliegues automáticos. Finalmente, presenta un ejemplo de pipeline de software usando herramientas como Jenkins, Gitlab y Sonarqube.

1. Integración y Entrega
continua
Prácticas clave en desarrollo de software
Romén Rodríguez Gil
@romenrg
TLP Innova 2017

2. Contenido
1. Introducción
2. Sobre la Integración y Entrega Continua
- Introducción y ventajas
3. Retos
- Pre-requisitos e implicaciones metodológicas
4. Ejemplo
- Estructura, pipeline, jenkinsfile y suma de herramientas utilizadas
5. La experiencia: proceso y siguientes pasos

3. 1. Introducción
Sobre mi y Platino

4. 1. Introducción
Sobre mi
Turawet

5. 1. Introducción
Platino
Gobierno de Canarias
Gobierno de España
AngularJS
Spring
Subversion
Git
Jboss
Tomcat
ActiveMQ
Java 6,7,8
Groovy Escalabilidad
ESB
Ant Maven
Servicios externos
MCD en desarrollo
Heterogeneidad Servicios heredados

6. 2. Integración y Entrega Continua:
prácticas clave en desarrollo ágil

7. 2. Sobre la Integración y Entrega Continua
Integración Continua

8. 2. Sobre la Integración y Entrega Continua
Integración Continua
- Definición (artículo de M. Fowler)
- Todos los desarrolladores integran su trabajo al mainline del sistema de
control de versiones frecuentemente (al menos una vez al día)
- Cada integración se verifica con un build automático
- Incluye la ejecución de pruebas
- Persigue detectar errores de integración tan pronto como sea posible
- Mejores prácticas
- Automatización total del proceso de construcción y despliegue de artefactos
- Ejecución de tests automatizados y otras verificaciones, como análisis de código
- Definición de conjunto de etapas en la construcción del software (pipelines)
- Permitir extensión con entrega continua, tras publicación del artefacto

9. 2. Sobre la Integración y Entrega Continua
Entrega Continua

10. - Definición
- Extensión natural de la Integración continua
- Cada cambio es potencialmente desplegable
- Diferencia con “despliegue continuo”: acción humana para activar despliegue
- La acción humana es muy sencilla. Solo es para controlar el “cuándo”
- Reducción drástica del tiempo de despliegues
- Mejores prácticas
- La infraestructura debe ser transparente desde el pipeline / job
- No se debe ceder al impulso de perder las planificaciones e hitos
- Aprovechar el tiempo ganada en la automatización para evitar la deuda técnica
2. Sobre la Integración y Entrega Continua
Entrega Continua

11. - Generales
- Rápida detección de errores (funcionales y de integración)
- Mejora del trabajo en equipo
- Aumento de la productividad (ej. - cambios de contexto en corrección de errores)
- Mucho mayor control sobre los despliegues
- Drástica reducción del tiempo dedicado a los despliegues
- Reducción de la sobrecarga de trabajo por ticket gracias a automatismos
- Otros (dependiendo del proyecto pueden ser derivados del refactoring necesario)
- Progreso en concepto de proyectos auto-contenidos* (tests y clientes)
- Mejora de estructura y mantenimiento de los tests (por pipelines)
- Mejoras en la gestión de dependencias entre servicios
2. Sobre la Integración y Entrega Continua
Ventajas

12. 2. Sobre la Integración y Entrega Continua
¿Y el Despliegue Continuo?
El despliegue se realiza automáticamente
si todo ha ido bien

13. - No apto para todos los proyectos
- Si tenemos un proceso de control humano por cliente o product manager
- Si tenemos integradores que deben adaptarse
- Si debemos dar formación a los usuarios tras los cambios en la UI
- ...
2. Sobre la Integración y Entrega Continua
Despliegue continuo

14. 3. Retos:
Pre-requisitos e implicaciones metodológicas

15. - Separación de tests (leer más)
- Tests unitarios
- Código propio de una funcionalidad concreta (ej. método de clase)
- Utilizan mocks o stubs para reemplazar sistemas externos
- Tests de integración
- Integración de funcionalidad (ej. método de clase) con sistemas que utiliza
- Caso anterior pero sin reemplazar las llamadas externas
- Ej: método “registrarEntrada” (SRE). Llama a entre otros servicios
- Tests end-to-end o “de sistema” (también serían los “tests aceptación” en Platino)
- Invocan interfaz del sistema y verifican el resultado
- En Platino son la mayoría (peculiaridad: UI es WSDL, no GUI)
- Consumen WS y verifican respuesta (indirectamente prueban integración)
3. Retos
Pre-requisitos (1/6)

16. - Estructura auto-contenida de proyectos, incluyendo:
- Tests
- Para que el pipeline pueda ejecutarlos
- Clientes
- Para poder escribir tests end-to-end
- Componentes auxiliares
- Ej: Generador de wsdl
- Componentes desplegables
- Artefactos principales
- Otros, opcionales pero deseables
- Ej. Features SMX (para permitir “updates”)
3. Retos
Pre-requisitos (2/6)

17. - Entorno de Integración
- Lugar donde desplegar artefacto bajo prueba
- Para tests end-to-end debemos desplegar el artefacto y consumir su WSDL
- También las dependencias del artefacto
- Si se tiene un ESB (ej. Platino) puede que estén acoplados
- tanto el artefacto en proceso de construcción
- como otros servicios de los que se dependen
- Para terceros externos podemos consumir su entorno de pruebas o sandbox
- (Algunas cosas se pueden compartir con DES)
3. Retos
Pre-requisitos (3/6)

18. - Capacidad para despliegues automáticos en entorno IC
- Propias de los contenedores / servidores de aplicaciones usados
- Jboss: jboss-as-maven-plugin
- SMX: Pax-Exam
- Problemas: no nos permitía levantar automáticamente un SMX4 con
nuestras dependencias
- Desarrolladas a medida
- Ej: Platino-despliegues
- Herramienta para desplegar artefactos de Platino programáticamente
- Específico para Platino, con todos sus conceptos y su heterogeneidad
3. Retos
Pre-requisitos (4/6)

19. - Herramientas para definición de pipelines
- Previo a Jenkins 2
- Jobs de Jenkins tradicionales
- Plugins no oficiales para pipelines
- Tras Jenkins 2 (publicado el 20 de Abril de 2016)
- Se incorporan los pipelines de forma nativa
- Jenkinsfiles
- Código groovy
- Dos tipos de sintaxis: programática y declarativa
3. Retos
Pre-requisitos (5/6)

20. - Artefactos independientes del entorno
- Artefactos previos contienen información de configuración dentro del
entorno.
- Propiedades de servidores a los que consulta
- Claves
- Propiedades externas
- Ej: uso de Spring Cloud Config en Platino
- El artefacto generado está disponible para ser desplegado en cualquier
entorno.
3. Retos
Pre-requisitos (6/6)

21. - Commits atómicos y push diarios
- Cada commit representa un único cambio y debemos intentar hacer push diarios
- Evitar caer al caos con la entrega continua
- Conservar los hitos / sprints es importante a nivel metodológico, aunque ahora
sea un proceso rápido y mucho más sencillo
- Aprovechar tiempo ganado con IC/EC para reducir la deuda técnica
- Mantener y mejorar tests, mejorar diseño de los servicios, mejorar naming...
- Priorizar la resolución de fallos en el entorno de IC
- Si un cambio nuestro genera un problema en el entorno, solucionarlo antes de
continuar con nuevas tareas
3. Retos
Implicaciones metodológicas

22. 4. Ejemplo:
Pipeline del Cl@ve, Platino

23. 4. Ejemplo
Pipeline de Cl@ve, Platino

24. 4. Ejemplo
Jenkinsfile Cl@ve, Platino (1/2)
stage('Preparación') {
println "*** groovy version: "+GroovySystem.version
checkout scm
mvnHome = tool 'M3'
sonarRunnerHome = tool 'sonar-scanner_2.8'
sh "'${mvnHome}/bin/mvn' clean deploy -pl !servicio-clave-platino-service"
}
stage('Compilación') {
sh "cd servicio-clave-platino-service && '${mvnHome}/bin/mvn' clean compile"
}
stage('Tests unitarios') {
sh "cd servicio-clave-platino-service && '${mvnHome}/bin/mvn' test"
}
stage('Empaquetado') {
sh "cd servicio-clave-platino-service && '${mvnHome}/bin/mvn' package -DskipTests"
}
1
2
3
4

25. 4. Ejemplo
Jenkinsfile Cl@ve, Platino (2/2)
try {
stage('Tests de integración y end-to-end') {
sh "cd servicio-clave-platino-service && '${mvnHome} /bin/mvn' platino-despliegues:integration -Dcomando=rerun” +
"failsafe:integration-test failsafe:verify"
}
stage('Análisis estático de código') {
// ...
}
stage('Validación y despliegue en repositorio') {
// ...
}
}
catch (err) {
stage ('Rollback y notificación de error') {
sh "cd servicio-clave-platino-service && '${mvnHome}/bin/mvn' platino-despliegues:integration
-Dcomando=rollback"
emailext(subject: "Importante: Problemas en '${env.JOB_NAME}' tras tu commit",
to: emailextrecipients([[$class: 'CulpritsRecipientProvider'], [$class: 'RequesterRecipientProvider']]),
body: "Por favor, revisa los detalles en: ${env.BUILD_URL} e intenta solucionarlo cuanto antes [...]")
}
throw err;
}
5
6
7
8

26. 4. Ejemplo
Estructura tipo
En proyectos con más de un
bundle deben estar en un
módulo de tests
Cliente
Pipeline
platino-despliegues-maven-plugin
(IntegrationMojo)
maven-failsafe-plugin
maven-deploy-plugin

27. 4. Ejemplo
Ejemplo: platino-despliegues
Parámetros IntegrationMojo:
- Comando
- “rerun”/“update” (despliegue)
- “validate”
- “rollback”
- Módulo
- Versión

28. 4. Ejemplo
Herramientas utilizadas (Gitlab - 1/3)

29. 4. Ejemplo
Herramientas utilizadas (Sonarqube - 2/3)

30. 4. Ejemplo
Herramientas utilizadas (Jenkins - 3/3)

31. 5. La experiencia
El proceso y siguientes pasos

32. - Debate sobre arquitectura de servicios / microservicios
- Definición de las fases de IC y EC
- Analizar plugins existentes para desplegar en contenedores elegidos
- Primer pipeline creado con Jenkinsfile
- Detección de principales problemas específicos del proyecto
- Llevar a cabo desarrollos a medida necesarios
5. La experiencia
El proceso

33. 5. La experiencia
Detección de principales problemas
- Los principales problemas surgidos son específicos del proyecto
- Estructuración de los servicios, clientes y tests
- Reorganización hacia un modelo de proyectos auto-contenidos, con clientes y
tests estructurados dentro de los servicios
- Se están separando los tests por tipo (unitarios, integración, end-to-end)
- Servidores de aplicaciones antiguos y heterogéneos
- Problemas con la ejecución programática de tests end-to-end en SMX4
- Necesidad de desarrollo a medida de herramienta de despliegues
- Es posible una alta complejidad de la herramienta si hay cantidad de
sistemas heterogéneos a incluir y unelevado número de funcionalidades
requeridas

34. 5. La experiencia
Platino-despliegues

35. - Gestión de pipelines por ramas y cambio en 2 ramas en mismo hito
- El resto de servicios no sabe cuál de las dos versiones se va a encontrar
- Podríamos integrar solo “develop” o asumir posibles problemas
- Restringir ejecuciones simultáneas de pipelines (ej. múltiples servicios)
- El entorno de IC es compartido y causaría inconsistencias parando y arrancando
- Contemplar el caso de despliegues extraordinarios
5. La experiencia
Siguientes pasos (1/4)

36. - Tarea de generación de “releases”
- La generación de releases podría ser transparente para el pipeline
- Podría haber una tarea en despliegues que cambiara el POM, quitando el
-SNAPSHOT y al hacer push del nuevo POM se lanzaría el pipeline
- Utilización de webhooks en Gitlab en lugar de polling desde Jenkins
- Automatizar despliegues de DES desde IC
- Posibilidad para validar completamente la integración entre módulos cada día
- Realizar cada tarde/noche un despliegue a DES con los cambios de IC
- Tras el despliegue, los tests de monitorización (end-to-end) detectarían
posibles errores de integración adicionales
- Ej: cambios de interfaz de nuevos módulos incluidos en IC ese día
5. La experiencia
Siguientes pasos (2/4)

37. Integración y Entrega
continua
Prácticas clave en desarrollo de software
TLP Innova 2017
Romén Rodríguez Gil
@romenrg