ponele el turbo al dev team de tu startup

Ponele el TURBO al Dev Team de tu Startup

Martin 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 y

manejar un sitio de mucho tráfico, siendo un equipo muy chico.

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.

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".

(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 :))

(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.

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

Son cosas relativamente fáciles de implementar una vez que uno ya las

conoce

Y eso vamos a compartir ahora...

Lo mejor de todo...

TURBOCómo ponerle el

a tu equipo?

La pregunta del millón:

URBO

T

URBO

Testeos Unitarios/Funcionales

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.

Testeos unitarios/funcionales - Tips

Podemos estar todo el dia hablando de testeos. En nuestra experiencia hay

dos cosas que son vitales...

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).

Que corran TODOS!

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.

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.

Que corran rápido!

Que corran rápido!

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.

URBO


Un Server de Integración Continua

RBO


● 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.

Jenkins CI (el server de integracion continua)

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.

Jenkins CI - Resultados

● 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.

Jenkins CI - Tips

GitHub Pull Request Builder

Ping via IRC

Jenkins - Plugins

● Mejorar cobertura de testeos JS y la frecuencia con la que los corremos.

● Selenium Tests:○ Optimizar su performance.○ Armar casos más complejos.○ Correrlos :)

Jenkins & Testing - Futuro


RBO



Real Error Reporting

BO


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...


● 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.


● 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.

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.

En sintesis

=

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...



BO




Bocha de Deploys

O


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.

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.

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!

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 changelog es "crowsourceado".● Para los curiosos, usamos más que nada

Fabric, una Python lib.

http://docs.fabfile.org/

http://docs.fabfile.org/

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".

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.



Bocha de Deploys

O




Bocha de deploys

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.


● 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.

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...

HABEMUS TURBO

Pero... cómo empiezo?

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.

Gracias!

Martin [email protected]@msinia

ponele el turbo al dev team de tu startup

Documents