Integracion y Entrega Continua - TLP Innova 2017

Integración y Entrega continua

Prácticas clave en desarrollo de software

Romén Rodríguez Gil @romenrg

TLP Innova 2017

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

1. Introducción

Sobre mi y Platino

1. Introducción

Sobre mi

Turawet

1. Introducción

Platino

Gobierno de Canarias

Gobierno de España AngularJS Spring Subversion Git Jboss Tomcat ActiveMQJava 6,7,8 Groovy EscalabilidadESB Ant MavenServicios externos

MCD en desarrollo Heterogeneidad Servicios heredados

2. Integración y Entrega Continua:

prácticas clave en desarrollo ágil


Integración 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

https://martinfowler.com/articles/continuousIntegration.html


Entrega Continua

- 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


Entrega Continua

- 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


Ventajas


¿Y el Despliegue Continuo?

El despliegue se realiza automáticamente si todo ha ido bien

- 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

- ...


Despliegue continuo

3. Retos:

Pre-requisitos e implicaciones metodológicas

- 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)

http://endoflineblog.com/unit-acceptance-or-functional-demystifying-the-test-types-part1

https://stackoverflow.com/a/463782

- 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


- 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


- 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


- 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


- 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


- 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

4. Ejemplo:

Pipeline del Cl@ve, Platino

4. Ejemplo

Pipeline de Cl@ve, Platino

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

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

67

8

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-pluginmaven-deploy-plugin

4. Ejemplo

Ejemplo: platino-despliegues

Parámetros IntegrationMojo:

- Comando - “rerun”/“update” (despliegue) - “validate” - “rollback” - Módulo - Versión

4. Ejemplo

Herramientas utilizadas (Gitlab - 1/3)

4. Ejemplo

Herramientas utilizadas (Sonarqube - 2/3)

4. Ejemplo

Herramientas utilizadas (Jenkins - 3/3)

5. La experiencia

El proceso y siguientes pasos

- 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

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

5. La experiencia

Platino-despliegues

- 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)

- 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)

Integración y Entrega continua

Prácticas clave en desarrollo de software

TLP Innova 2017

Romén Rodríguez Gil @romenrg

Integracion y Entrega Continua - TLP Innova 2017

Software

Transcript of Integracion y Entrega Continua - TLP Innova 2017