Ponele el TURBO al Dev Team de tu StartupMartin SiniawskiCo-founder & CTO de Streema@msinia
- Red social para oyentes radios.- +50,000 radios de todo el mundo.
- Empezamos hace 5 años y 1/2.
Nuestros dulces primeros años (3 y 1/2) Streema Team
- Empezamos hace 5 años y 1/2.- En los últimos años las cosas cambiaron! Streema Team (ultimo tiempo)
De qué vamos a hablar hoy?Técnicas y herramientas que nos permiten ejecutar muy rápido ymanejar un sitio de mucho tráfico,...
De qué vamos a hablar hoy?● Por qué empezamos esta búsqueda?● La pregunta del millón: Cómo ponerle el TURBO a tu equi...
Por qué emprendimos esta búsqueda?Teníamos dos sentimientos... - "Dos pasos hacia delante y uno para atrás". - "Tenemos qu...
(Antes)- Downtimes frecuentes sin entender causas.- Arreglamos/implementamos algo, perorompemos otra cosa.- Deploys cada m...
(Hoy)- Prácticamente no tenemos downtimespropios.- La mayoría de los errores nunca llega a prod.- Si llegan, nos damos cue...
(Hoy)
(Hoy)
(Hoy)
De acuerdo a nuestra experiencia... Hay pequeños mecanismos que hacen una gran diferencia en la velocidad y calidad...
Lo mejor de todo... Son cosas relativamente fáciles de implementar una vez que uno ya las conoce Y eso va...
La pregunta del millón: Cómo ponerle el TURBO a tu equipo?
TURBO
Testeos Unitarios/FuncionalesURBO
Testeos unitarios/funcionales● Nos costó entender su beneficio hasta implementarlos.● No hacemos TDD, intentamos que la ...
Testeos unitarios/funcionales - TipsPodemos estar todo el dia hablando de testeos. En nuestra experiencia hay dos cosa...
Que corran TODOS!
Que corran TODOS!● Tuvimos testeos que no estaban siendo corridos.● Los organizamos distinto a lo que nuestro test runne...
Que corran rápido!
Que corran rápido!Por qué?- Si no se corren rápidos es un freno para quealguien los corra.- Hay que enterarse rápido si al...
Que corran rápido!● Nosotros tackleamos el problema de la velocidad a principio de año.● El mayor problema se debía - y s...
Que corran rápido!
Testeos unitarios/funcionales - Tips1. Por favor no usen fixtures.2. Si realmente no hay tiempo, hacer tests más funcion...
Testeos Unitarios/FuncionalesURBO
Testeos Unitarios/FuncionalesUn Server de Integración ContinuaRBO
Jenkins CI (el server de integracion continua)● Realmente es muy fácil de tenerlo andando (en un 1 dia de hace?)...
Jenkins CI (el server de integracion continua)● Empezamos a usar Jenkins en Dic 11.● Buildeó nuestra webapp ~600 ...
Jenkins CI - Resultados
Jenkins CI - Resultados
Jenkins CI - Tips● Tests corren contra cualquier push a: ○ Nuestros forks. ○ Pull requests pre-mergeados. ○ Merges al m...
GitHub Pull Request Builder
Ping via IRC
Jenkins - Plugins
Jenkins & Testing - Futuro● Mejorar cobertura de testeos JS y la frecuencia con la que los corremos.● Selenium Tests: ○ ...
Testeos Unitarios/FuncionalesUn Server de Integración ContinuaRBO
Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBO
Real error reportingSituación:● Pusheamos codigo y pasa los tests.● Deployeamos a prod y al rato los servers se van a la...
Real error reporting● No todos los errores uno son detectables antes de prod: ○ No tengo suficiente cobertura de testeos...
Real error reporting● Usamos● Mucha introspeccion a nuestro backend.● Lo más jugoso (y aplicable acá) es: ○ Exceptions en...
New Relic - Tips● Tenerle un ojo encima sobretodo post- deploy. ○ App Server overview. ○ Errors.● Usar notifications pa...
En sintesis =
Real error detection - Futuro● Detectamos fenómeno los errores de backend... pero, qué pasa con los de frontend?● Estamo...
Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBO
Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBocha de DeploysO
Bocha de deploysPara poder tener una bocha de deploysse necesitan dos cosas: a. Un proceso de deploy trivial. b. Trabajar ...
Proceso de deploy● Nuestro proceso de deploy empezó a hacerse más engorroso.● Realmente molesto y time-consuming. Tendía...
Proceso de deploy● Dónde estaba la complejidad y molestia? ○ Armar un tag, con el release, viendo cuál es el número qu...
Proceso de deploy
Proceso de deploy - Tips● Tiene que ser trivial deployear a producción. En lo posible un "botón" que haga todo.● El chang...
Batches pequeñosQué problemas tuvimos nosotros? ○ Hay upside que no se captura. ○ Mucho mas jodido de hacer code-review....
Batches pequeños - Tips● Es más bien un tema de paradigma y disciplina.● Armar los proyectos/tareas en pequeños pedazito...
Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBocha de DeploysO
Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBocha de deploysOutsourcing a Servicios
Outsourcing a Servicios● Outsourcear todo lo que no sea core (a otros servicios).● Si se puede pagar y cumple los mínimos...
Outsourcing a Servicios● Nos lo tomamos bastante en serio.● Ejemplos que usamos: ○ Trello (Project Management). ○ Fl...
Outsourcing a Servicios - Tips● Estar siempre en la búsqueda de oportunidades.● Recordar que es una excelente forma de a...
HABEMUS TURBO
Pero... cómo empiezo?
Propuesta: Shippear todos los díasDe qué se trata?Hacer un deploy a producción al menos unavez por día.Por qué?● Fuerza a ...
Gracias!Martin Siniawskimartin@streema.com@msinia
Ponele el TURBO al Dev Team de tu Startup
Ponele el TURBO al Dev Team de tu Startup
Ponele el TURBO al Dev Team de tu Startup
Ponele el TURBO al Dev Team de tu Startup
Ponele el TURBO al Dev Team de tu Startup
of 69

Ponele el TURBO al Dev Team de tu Startup

Published on: Mar 4, 2016
Source: www.slideshare.net


Transcripts - Ponele el TURBO al Dev Team de tu Startup

  • 1. Ponele el TURBO al Dev Team de tu StartupMartin SiniawskiCo-founder & CTO de Streema@msinia
  • 2. - Red social para oyentes radios.- +50,000 radios de todo el mundo.
  • 3. - Empezamos hace 5 años y 1/2.
  • 4. Nuestros dulces primeros años (3 y 1/2) Streema Team
  • 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 ymanejar 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. (Antes)- Downtimes frecuentes sin entender causas.- Arreglamos/implementamos algo, perorompemos otra cosa.- Deploys cada mucho tiempo. Podían llegar apasar semanas sin deployear.- Errores durante mucho tiempo en producción(salvo que sean muy graves :))
  • 10. (Hoy)- Prácticamente no tenemos downtimespropios.- La mayoría de los errores nunca llega a prod.- Si llegan, nos damos cuenta casiinstantáneamente.- Deployeamos varias veces por día.
  • 11. (Hoy)
  • 12. (Hoy)
  • 13. (Hoy)
  • 14. 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
  • 15. Lo mejor de todo... Son cosas relativamente fáciles de implementar una vez que uno ya las conoce Y eso vamos a compartir ahora...
  • 16. La pregunta del millón: Cómo ponerle el TURBO a tu equipo?
  • 17. TURBO
  • 18. Testeos Unitarios/FuncionalesURBO
  • 19. 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.
  • 20. Testeos unitarios/funcionales - TipsPodemos estar todo el dia hablando de testeos. En nuestra experiencia hay dos cosas que son vitales...
  • 21. Que corran TODOS!
  • 22. 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).
  • 23. Que corran rápido!
  • 24. Que corran rápido!Por qué?- Si no se corren rápidos es un freno para quealguien los corra.- Hay que enterarse rápido si algo se rompió, elcontext switch mata! El número fetiche es 1. Difícil.
  • 25. 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.
  • 26. Que corran rápido!
  • 27. Testeos unitarios/funcionales - Tips1. 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.
  • 28. Testeos Unitarios/FuncionalesURBO
  • 29. Testeos Unitarios/FuncionalesUn Server de Integración ContinuaRBO
  • 30. 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.
  • 31. 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.
  • 32. Jenkins CI - Resultados
  • 33. Jenkins CI - Resultados
  • 34. 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.
  • 35. GitHub Pull Request Builder
  • 36. Ping via IRC
  • 37. Jenkins - Plugins
  • 38. 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 :)
  • 39. Testeos Unitarios/FuncionalesUn Server de Integración ContinuaRBO
  • 40. Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBO
  • 41. Real error reportingSituació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...
  • 42. 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.
  • 43. 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.
  • 44. 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.
  • 45. En sintesis =
  • 46. 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...
  • 47. Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBO
  • 48. Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBocha de DeploysO
  • 49. Bocha de deploysPara poder tener una bocha de deploysse necesitan dos cosas: a. Un proceso de deploy trivial. b. Trabajar en batches bien chiquitos.
  • 50. 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.
  • 51. 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!
  • 52. Proceso de deploy
  • 53. 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.
  • 54. Batches pequeñosQué problemas tuvimos nosotros? ○ Hay upside que no se captura. ○ Mucho mas jodido de hacer code-review. ○ Mucha mas probabilidad de mandarse una "cagadona".
  • 55. 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.
  • 56. Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBocha de DeploysO
  • 57. Testeos Unitarios/FuncionalesUn Server de Integración ContinuaReal Error ReportingBocha de deploysOutsourcing a Servicios
  • 58. 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.
  • 59. 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.
  • 60. 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...
  • 61. HABEMUS TURBO
  • 62. Pero... cómo empiezo?
  • 63. Propuesta: Shippear todos los díasDe qué se trata?Hacer un deploy a producción al menos unavez 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.
  • 64. Gracias!Martin Siniawskimartin@streema.com@msinia

Related Documents