Como multiples desplegues ayundan
a reducir riesgos
(y como hacerlos?)
Antes de hablar sobre tecnología…
Una pequeña historia de la vida real
lo que pasé en brasil…
con buses de línea
buses me llevan desde trabajo
a mi casa
buses tienen horarios
pero a (muchas) veces se retrasa
y a veces tienen pocas líneas
¿que comportamientos producen los intervalos y retrasos de buses?
¿si el bus esta lleno?
- espero más 30 minutos para otro?
- posiblemente lleno de nuevo
- acepto irme apretado?
un bus lleno es un gran riesgo
si tenemos un problema en el motor, muchas personas no van llegar donde quieren
las personas van ser agregadas al próximo bus
- que agranda el riesgo, y así continua…
¿si aun no estoy listo y veo el bus?
- corro por 5 minutos para llegar a tiempo?
- voy tranquilo, y espero por 30 minutos (o mas)?
variables del bus
- muchas personas = mas riesgos
- baja frecuencia = mas personas
algunas sugerencias para llegar mejor a su casa
- taxi
- uber
- tener una alta frecuencia de buses
la certeza de un bus próximo cambia el comportamiento
no más buses…
hablamos de computadores
el deployment lleva cambios desde trabajo
a su "casa"
- todos los cambios tiene como destino producción
- un cambio vive en producción, esta es su casa
variables del bus
- muchas personas = mas riesgos
- baja frecuencia = mas personas
variables del bus
- muchas personas = mas riesgos
- baja frecuencia = mas personas
variables del deploy
- muchos cambios = mas riesgos
- baja frecuencia = mas cambios
¿Y si tenemos un bus por año?
(No mas buses…)
¿Y si tenemos un deploy por año?
Envio:
- 1 cambio pequeño?
- 1 cambio grande?
- 1.000.000 cambios pequeños?
¿Y si me deploy anual tiene un problema?
Reviso y arreglo:
- 1 cambio pequeño?
- 1 cambio grande?
- 1.000.000 cambios pequeños?
¿Como es el comportamiento con deploys a cada 2 semanas?
- El cambio casi listo, corro para el deploy en esta semana?
- Espero 2 semanas, por causa de 2 dias más que necesitaba?
Correr para el bus tiene riesgos:
No vas a mirar bien los problemas en el camino
Puede ponerse en mas riesgo
Se queda sin aire
Correr con un cambio tiene riesgos:
No vas mirar bien los problemas en el camino
- Como voy impactar otros equipos?
- Como voy impactar la compania?
Puede ponerse en mas riesgo
- Estoy comprometiendo buenas practicas?
- Hice todas las pruebas necesarias?
Se queda sin aire
- Burnout
- Sentimiento de bombero todo los dias
¿Como es el comportamiento con deploys a cada 1 hora?
Es posible eligir no subir en el deploy de las 8AM
Mas algunos minutos y toma el deploy de las 9AM
Podemos enviar enviar cambios pequeños y probar como es el comportamiento en producción.
¿Como es el comportamiento con deploys a cada 10 minutos?
Si tengo un problema en producción, puedo simplemente hacer mas un deploy
- No es necesario un flujo de
hotfix - Pasamos a utilizar el flujo que siempre utilizamos para
hotfixes - Sabemos que es un buen flujo, incluso para
hotfixes, como utilizamos todo los dias
¿Pero, si no estoy listo con mi feature?
Deploy no es Release
Es posible escribir codigo, ponerlo en producción, pero no disponibilizar para el usuario
- Despliegue apagado (Feature Toggles)
- Canary release
- A/B testing
Despliegue apagado
- Agregamos flags (
Feature Toggles) en código para definir el flujo - Tenemos el deploy
- Mientras activo, activamos el nuevo flujo de codigo
- Si tenemos problemas, volvemos al flujo antiguo
- Sin los riesgos de deploy
Canary release
- Agregamos flags (
Feature Toggles) en código para definir el flujo - Tenemos el deploy
- Mientras activo, activamos el nuevo flujo de codigo para 1% de usuarios
- Caso vemos bien, agrandamos a 10% de usuarios
- 50%, 55%, 70%, …. hasta 100%
A/B testing
- Agregamos flags (
Feature Toggles) en código para definir el flujo - Tenemos el deploy
- Mientras activo, cambiamos el flag para 50% de los usuarios
- Medimos y elijimos el mejor
En resumen
Variables del deploy
- Muchos cambios = Mas riesgos
- Baja frecuencia = Mas cambios
- Deploys más frecuentes reducen el tamaño de los cambios
- Cambios pequeños ayudan a identificar problemas
- Un Deploy grande tiene riesgo
- Un Release grande tiene riesgo
- Un Deploy grande que también es un Release, és doble el riesgo
¡Gracias!
Bruno Tavares