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
Integracion continua en Corenet
By YBK
Integracion continua en Corenet
Presentación para mostrar los trabajos realizados en Corener en temas de integración continua
- 1,866