Integración continua

en Corenet    

Integración continua

en Corenet   

Objetivo:

arrancar un proyecto de “testing” de aplicaciones en real

aprender las ventajas e inconvenientes de este enfoque

intro teórica

el sesudo público que se dedica a esto, tiende a englobarlo bajo el epígrafe de...

continuous integration

algunos principios

  • mantener un repositorio único
  • automatizar la generación de builds
  • que éstos sean auto-testeables
  • acelerar el proceso de generación de builds
  • probar en clones de producción
  • que sea fácil conseguir el último ejecutable
  • que todo el equipo pueda "ver lo que pasa”
  • automatizar el despliegue de la aplicación

si no les gustan estos, les puedo dar otros…

¿Cómo conseguirlo?

¿Cómo conseguirlo?

Los desarrolladores harán los “updates” en su entorno de trabajo... por ejemplo su PC; 

El servidor de integración comprobará si hay cambios en el repositorio: hará un "update" y generará los “builds”, a los que etiquetará adecuadamente, y publicará automáticamente 

Para cada nuevo build el servidor de integración ejecutará pruebas unitarias y de integración

El servidor genera información para analizar resultados: (logs, mails, web,...) 

Sí algo falla....el equipo es advertido...y corrige el fallo lo antes posible (un "build" erróneo debe estar el menos tiempo posible roto)

y...

una de las (grandes) ventajas de este enfoque, es que es fácil detectar dónde está el problema ( ...en general...)

ya que los cambios realizados son pequeños y permite al equipo corregir el código defectuoso rápidamente

el objetivo final reducir los riesgos en los despliegues

y

corregir los errores lo antes posible

y reducir tareas rutinarias

Nuestra experiencia

en Corenet

Uso de Subversión

como repositorio único

todo lo que se necesite para generar un build debe estar en este repositorio: aplicaciones, tests, librerías de terceros, frameworks, settings IDE, documentación, ayudas, etc…

Integración builds

en Corenet utilizamos Cruise Control como servidor de test

Automatización builds

Cada 5 minutos comprueba el repositorio, hace los updates al entorno DEV y genera un nuevo build y ejecuta los test individuales y de integración previstos

Servidor de test

Cruise Control

Conjunto de 

  • disparadores (triggers)
  • tareas (tasks)
  • salidas (artefacts)

Cruise Control

Disparadores:

  • lanza tareas cada x tiempo, por evento, ...

Tareas:

  • MSBuild: Para la generación automática de builds
  • Nunit+Selenium: para la generación de pruebas 
  • Documentador (Sand Castle)
  • FxCop: analítica de código
  • DupFinder: detecta código duplicado
  • etc...

Salidas:

  • logs, mails: análisis resultados

Una vez llegado aquí...

parece clara la necesidad de disponer del mayor número de test automatizados

Tipos de pruebas

...y alcance

locales

las ejecuta el desarrollador en su entorno

buenas prácticas en programación, reutilización de pruebas ya generadas,… 

build

Unos test de corto alcance y duración al ejecutarse cada build

locales

  • envíos de correos, pings a servidores,...
  • que la base de datos está accesible. Que se puede leer, modificar, borrar y dar de alta.
  • tiempos de ejecución de alguna query para detectar problemas (puede que esta vaya a otro bloque de pruebas de rendimiento)
  • crear, borrar una comunicación. Sellar un comunicación. Enviar una comunicación (...)
  • pruebas del servidor de ficheros: leer, reemplazar, editar, borrar un fichero.
  • generar pdf, csv,...
  • accesos con diferentes perfiles de la aplicación. 

diarios

de mayor empaque y mayor duración: a ejecutarse cada día

locales

build

 

  • pruebas con web services
  • pruebas de reglas de negocio de la aplicación
  • pruebas de flujo de proceso
  • provocar situaciones de error
  • ...

selectivos

en profundidad o selectivos: a ejecutarse discrecionalmente cuando se estime necesario

diarios

locales

build

carga, seguridad,...

test de carga, escalabilidad, ...

...por Explotación

selectivos

diarios

locales

build

¿Qué probamos?

para realizar las pruebas, se requiere expertise en la aplicación y su entorno y expertise en el proceso de generación de test (selenium, integración, adecuación,…)

¿Alcance?

las pruebas a realizar pueden ser casi ilimitadas:

hay que elegir que aspectos probar

 es un tema económico y de coste

  • en un ejemplo de eCommerce, estaría más claro lo que conviene probar.
  • en un entorno Administración, es más difícil

Criterio

minimizar el impacto externo de la aplicación

Evolución

etapas en el desarrollo de nuestro entorno de pruebas

evolución

  • pruebas solo con Selenium
  • exportación de una prueba con Selenium y codificar prueba unitaria en C#
  • componentizar estas pruebas iniciales para facilitar su generalización
  • carga de pruebas desde base de datos (asislar código y “casos de prueba”)
  • generación de un diccionario de casos de pruebas en base de datos
  • alimentación de este diccionario con casos reales procedentes de producción

evolución

  • desarrollo de aplicación ad-hoc para la carga de pruebas en el diccionario: filtros de carga
  • esta diccionario de pruebas, se pueden ejecutar automáticamente en los procesos de build, en diferido o manualmente
  • desarrollo un módulo (plugin Nunit), para explotar y analizar la información resultante de estas pruebas en base de datos

todo esto integrado en Cruise Control

operativa

PRO

FILTRO

APP

Diccionario

PRE

DEV

Cruise Control

Desventajas

  • curva de aprendizaje

  • selenium

  • mantenimiento de test

  • nuevos módulos

  • ...

demo

Integración continua

en Corenet