integracion y entrega continua - tlp innova 2017
TRANSCRIPT
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
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. 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
- 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
- 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
2. Sobre la Integración y Entrega Continua
¿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
- ...
2. Sobre la Integración y Entrega Continua
Despliegue continuo
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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
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
- 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
- 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)