5. - Empezamos hace 5 años y 1/2.
- En los últimos años las cosas cambiaron!
Streema Team (ultimo tiempo)
6. De qué vamos a hablar hoy?
Técnicas y herramientas que nos
permiten ejecutar muy rápido y
manejar un sitio de mucho tráfico,
siendo un equipo muy chico.
7. De qué vamos a hablar hoy?
● Por qué empezamos esta búsqueda?
● La pregunta del millón:
Cómo ponerle el TURBO a tu equipo?
● Espacio para compartir otras experiencias,
ideas, dudas, etc.
8. Por qué emprendimos esta búsqueda?
Teníamos dos sentimientos...
- "Dos pasos hacia delante y uno para atrás".
- "Tenemos que avanzar más rápido, y parece
que todavia hay margen para hacerlo".
9.
10. (Antes)
- Downtimes frecuentes sin entender causas.
- Arreglamos/implementamos algo, pero
rompemos otra cosa.
- Deploys cada mucho tiempo. Podían llegar a
pasar semanas sin deployear.
- Errores durante mucho tiempo en producción
(salvo que sean muy graves :))
11. (Hoy)
- Prácticamente no tenemos downtimes
propios.
- La mayoría de los errores nunca llega a prod.
- Si llegan, nos damos cuenta casi
instantáneamente.
- Deployeamos varias veces por día.
15. De acuerdo a nuestra experiencia...
Hay pequeños mecanismos que
hacen una gran diferencia en la
velocidad y calidad de los
resultados que uno puede obtener
16. Lo mejor de todo...
Son cosas relativamente fáciles de
implementar una vez que uno ya las
conoce
Y eso vamos a compartir ahora...
20. Testeos unitarios/funcionales
● Nos costó entender su beneficio hasta
implementarlos.
● No hacemos TDD, intentamos que la
cobertura no baje.
● La mayoría es de backend (Python), algo de
JS y Selenium.
21. Testeos unitarios/funcionales - Tips
Podemos estar todo el dia hablando de
testeos. En nuestra experiencia hay
dos cosas que son vitales...
23. Que corran TODOS!
● Tuvimos testeos que no estaban siendo
corridos.
● Los organizamos distinto a lo que nuestro
test runner (nose) espera.
● Armamos una clase especial que hace la
deteccion (un test selector).
25. Que corran rápido!
Por qué?
- Si no se corren rápidos es un freno para que
alguien los corra.
- Hay que enterarse rápido si algo se rompió, el
context switch mata!
El número fetiche es 1'. Difícil.
26. Que corran rápido!
● Nosotros tackleamos el problema de la
velocidad a principio de año.
● El mayor problema se debía - y se debe - a
los fixtures.
○ Refactoreamos testeos para que no los
usen.
○ Implementamos fixture bundling.
28. Testeos unitarios/funcionales - Tips
1. Por favor no usen fixtures.
2. Si realmente no hay tiempo, hacer tests más
funcionales.
3. Cuando aparece un bug que los testeos no
agarran, intentar armar un test que lo haga.
4. Usar Selenium para hacer testeos
funcionales de los JS.
31. Jenkins CI
(el server de integracion continua)
● Realmente es muy fácil de tenerlo andando
(en un 1 dia de hace?).
● Seguridad que esos preciados testeos
efectivamente se estén corriendo.
● No dependemos de nuestra
memoria/ganas/disciplina.
32. Jenkins CI
(el server de integracion continua)
● Empezamos a usar Jenkins en Dic 11'.
● Buildeó nuestra webapp ~600 veces
(testeos Python).
● Detectó 117 que fallaron.
35. Jenkins CI - Tips
● Tests corren contra cualquier push a:
○ Nuestros forks.
○ Pull requests pre-mergeados.
○ Merges al master.
● Usar el "GitHub Pull Request Builder".
● Clave enterarse rápido, por lo que hay un
ping via email/IRC ni bien falla el build.
39. Jenkins & Testing - Futuro
● Mejorar cobertura de testeos JS y la
frecuencia con la que los corremos.
● Selenium Tests:
○ Optimizar su performance.
○ Armar casos más complejos.
○ Correrlos :)
42. Real error reporting
Situación:
● Pusheamos codigo y pasa los tests.
● Deployeamos a prod y al rato los servers se
van a la goma.
● Nos sorprendemos, ya que todo parecia
andar bien...
43.
44. Real error reporting
● No todos los errores uno son detectables
antes de prod:
○ No tengo suficiente cobertura de testeos.
○ "Parecería" andar bien, pero no lo probamos con
carga real.
○ Jamás me imaginé que los usuarios podrían hacer
eso!
Resulta vital tener algún tipo de sistema que
ayude a detectar errores en prod.
45. Real error reporting
● Usamos
● Mucha introspeccion a nuestro backend.
● Lo más jugoso (y aplicable acá) es:
○ Exceptions en tiempo real.
○ Response time del backend en tiempo real,
con transacciones más lentas, etc.
46.
47.
48. New Relic - Tips
● Tenerle un ojo encima sobretodo post-
deploy.
○ App Server overview.
○ Errors.
● Usar notifications para error-rate thresholds.
● Capacity Analysis (feature +o- nuevo). Nos
hubiera servido para solucionar downtimes.
50. Real error detection - Futuro
● Detectamos fenómeno los errores de
backend... pero, qué pasa con los de
frontend?
● Estamos en proceso de tacklear ese
problema...
53. Bocha de deploys
Para poder tener una bocha de deploys
se necesitan dos cosas:
a. Un proceso de deploy trivial.
b. Trabajar en batches bien chiquitos.
54. Proceso de deploy
● Nuestro proceso de deploy empezó a
hacerse más engorroso.
● Realmente molesto y time-consuming.
Tendíamos a evitar deployear.
● Mucho tiempo desde implementacion hasta
deployment. Bugfixes rápidos eran
impensados.
55. Proceso de deploy
● Dónde estaba la complejidad y molestia?
○ Armar un tag, con el release, viendo cuál es el
número que corresponde asignarle.
○ Armar el changelog a mano, mirando los commits
que entran desde el último release.
○ Pedido de credenciales.
○ Sacar nodos de un load balancer a mano.
○ Tener que repetir el proceso para varios servers.
De 20' de sufrimiento
a 30'' de placer!
57. Proceso de deploy - Tips
● Tiene que ser trivial deployear a producción.
En lo posible un "botón" que haga todo.
● El changelog es "crowsourceado".
● Para los curiosos, usamos más que nada
Fabric, una Python lib.
58.
59. Batches pequeños
Qué problemas tuvimos nosotros?
○ Hay upside que no se captura.
○ Mucho mas jodido de hacer code-review.
○ Mucha mas probabilidad de mandarse una
"cagadona".
60. Batches pequeños - Tips
● Es más bien un tema de paradigma y
disciplina.
● Armar los proyectos/tareas en pequeños
pedazitos, que pueden ser deployeados fácil
e independientemente.
● Esforzarse para que las cosas no se
acumulen y se deployeen rapido.
63. Outsourcing a Servicios
● Outsourcear todo lo que no sea core (a otros
servicios).
● Si se puede pagar y cumple los mínimos
requerimientos, vale la pena probarlo.
● Usarlo hasta que quede chico.
● Todo lo outsourceado es más espacio y
recursos para nuestra especialidad.
64. Outsourcing a Servicios
● Nos lo tomamos bastante en serio.
● Ejemplos que usamos:
○ Trello (Project Management).
○ Flowdock (IRC).
○ GitHub.
○ Searchify (fulltext search, IndexTank compat).
○ Sauce Labs (frontend testing, Selenium).
○ New Relic.
○ Linode/AWS.
○ ... y siempre estamos en la búsqueda de más.
65. Outsourcing a Servicios - Tips
● Estar siempre en la búsqueda de
oportunidades.
● Recordar que es una excelente forma de
acercarse a especialistas que conocen las
best practices.
● Sin embargo, no siempre funciona...
68. Propuesta: Shippear todos los días
De qué se trata?
Hacer un deploy a producción al menos una
vez por día.
Por qué?
● Fuerza a que todas las piezas estén en su
lugar.
● Se tiene feedback rápido con data real.
● Motivación para todos los involucrados.
