Director's Cut: Now with unicorns!
Pruebas unitarias
Pruebas de integración
Pruebas de carga
Despliegue
Despliegue continuo
Monitorización
Demo completa
Ni añadir pruebas a lo loco
... ni porque sí (TDD)
Ni paquetes propietarios
Ni múltiples lenguajes de programación
Y definitivamente sin trucos dependientes del lenguaje
Pufff...
No, si tengo que hacerlas...
Es que... señooo... no he hecho la tarea...
#fail
#EpicFail
Prueba usando código
Guarda las pruebas
Córrelas todas juntas
Evita los errores de regresión
Guardamos todos los tests y los lanzamos
Tres reglas básicas:
JUnit, CppUnit, xUnit
JavaScript: NodeUnit, Jasmine, mocha
Pruebas asíncronas: QUnit (cliente)
Opción bricolage
Diseña tu sistema para que sea testable
¿Funciona para tres valores?
https://github.com/alexfernandez/demo-deployment
https://github.com/alexfernandez/testing
ok(), nok(), assert(), assertEquals()
Suite de prueba
Prueba del sistema completo
Debe pasar por todos los puntos del sistema:
Petición → Servidor web → Base de datos
Ortogonales con pruebas de sistema
¿Cuántas suites de prueba? Cuantas más mejor
Llamado a veces: maqueta, preproducción, staging...
Simulación de datos
Pruebas autocontenidas
(limpieza al terminar)
Certificación final
Lanzamos peticiones sintéticas contra un servidor
Medimos la respuesta (tiempo total, latencia...)
En condiciones lo más realistas posibles
Benchmark < Petición real < Flujo real < Producción
Peticiones por segundo vs concurrencia
Latencia vs Peticiones / segundo
Fuente: BitCurrent
Diseña un API de control
Arranca y para el sistema completo usando el API
Pruebas autocontenidas: limpia al terminar
Siguen aplicando las tres reglas básicas:
Automática:
https://github.com/alexfernandez/demo-deployment/blob/master/lib/integration.js
https://github.com/alexfernandez/loadtest
$ node index.js
$ loadtest -n 10000 -c 10 http://localhost:12322/3/4
Automática:
https://github.com/alexfernandez/demo-deployment/blob/master/lib/loadtest.js
Fuente: Norman Rockwell
Poner el código en producción
O de cómo hacer que el código tenga valor
Los aficionados hablan de programación;
los profesionales se preocupan del despliegue
Anónimo
Actualización de código
Instalación de librerías
Pruebas
Puesta en producción
Puesta en producción de código nuevo
Nuevas funcionalidades o cambios
Acumulación de fallos
¡Una pesadilla!
Conclusión: cuantos menos despliegues, mejor
Fuente: comicvine?
Fuente: Super Pirulo Txou
Fuente: arte.about.com?
¿Qué tal si desplegamos más a menudo?
Mejor muchos cambios pequeños que uno grande
Ciclos más cortos → mayor eficiencia
No nos alejamos del equilibrio
Entropía mínima: Proceso reversible
Menos entropía → menos lío
es un despliegue bien hecho
Fuente: twotsi.com
Repositorio de código
Una máquina para integrar
Entorno de pruebas
Muchas máquinas para desplegar
Despliegue integrado con el repositorio
Cada cambio lanza una integración (CI)
Cada integración lanza un despliegue (CD)
De nuevo las tres reglas básicas:
Travis CI:
Demo deployment:
https://github.com/alexfernandez/demo-deployment
[![Build Status](https://secure.travis-ci.org/alexfernandez/demo-deployment.png)](http://travis-ci.org/alexfernandez/demo-deployment)
https://github.com/alexfernandez/deployment
https://console.aws.amazon.com/ec2/v2/home?region=eu-west-1#Instances:
$ deployment-server --token gs9f03tkddmi23wi --testdir . --timeout 20 --name demo --exec "echo success"
$ supervisor index.js
http://remote:3470/deploy/gs9f03tkddmi23wi/manual
https://github.com/alexfernandez/demo-deployment/settings/hooks
Servidor que suma (supervisor)
Servidor de despliegue
Acceso a despliegue manual
Webhook en GitHub
Cambio de código → integración → despliegue
https://console.aws.amazon.com/ec2/v2/home?region=eu-west-1#Instances:
http://remote:3470/deploy/nn0zwyqgx3ek5qqz/manual
$ git clone https://github.com/alexfernandez/demo-deployment.git
$ deployment-server --token nn0zwyqgx3ek5qqz --name prod --dir .
Usa lo que proporciona el entorno: git pull, npm install, npm test
No reinicia el servicio: supervisor, forever, Upstart, systemd
Notificación
Fuente: bleedingcool
Dale visibilidad a las tripas de tu software
Monitorización técnica: peticiones/segundo, latencia
Monitorización de negocio: el software hace lo que debe
Cuanto más monitorices, ¡mejor!
Guarda un rastro de todo
Guarda logs específicos
Archiva o borra
¡Revisa el log!
(Fuente: Wikipedia)
¿He sido yo?
Verifica el sistema a intervalos
Haz que los errores vengan a ti
Crea alarmas
Envía los errores que requieran intervención humana
Evita que la señal se ahogue en el ruido
Sistema de correo
Intervalos de monitorización variables:
cada cinco minutos
cada hora
cada día
Cron o similar
Amazon EC2:
https://console.aws.amazon.com/ec2/v2/home?region=eu-west-1#Instances:
Amazon CloudWatch:
Pruebas unitarias
↓
Pruebas de integración
↓
Pruebas de carga
↓
Despliegue de código
↓
Monitorización
El despliegue continuo está preparado para tu organización
¿Está tu organización preparada para el despliegue continuo?
Se requiere un "integrador" boss
Los problemas de build tienen máxima prioridad:
Nadie se va a casa con el build rotoVe poco a poco
Cada mejora debe dar valor al negocio
Y todas juntas deben amplificarse
Mantén la velocidad del equipo
Pruebas asíncronas:
http://www.godtic.com/blog/2013/07/11/pruebas-asincronas-en-node-js/
Pruebas de carga:
http://www.godtic.com/blog/2013/08/27/pruebas-de-carga/
https://slid.es/alexfernandez/pruebas-automaticas-y-despliegue-continuo