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
Fuente: United States Navy
Pufff...
No, si tengo que hacerlas...
Es que... señooo... no he hecho la tarea...
Fuente: Alex E. Proimos
Fuente: S.H.I.T.#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

Fuente: NPCC
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
[](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