¿Cómo gestiona Etsy el desarrollo y las operaciones? Desarrollador de registros, desarrollo de aplicaciones

En 2010, crecimos el equipo de ingeniería bastante rápido, pasando de 20 a aproximadamente 70, y el resto de la compañía también creció rápidamente. A medida que crecimos, la velocidad general ha sido realmente importante para nosotros, y hemos ajustado continuamente nuestros procesos, herramientas y cultura para respaldar eso. Escribí sobre algunos de los principios detrás de todo esto en mi blog durante el verano: http://blog.chaddickerson.com/20…

En este momento, los desarrolladores se dividen en varios equipos pequeños, generalmente de 3 a 7 ingenieros. Estos equipos están emparejados con un gerente de producto y un diseñador, y hay algún movimiento entre los equipos según sea necesario. Todos los diseñadores del código de Etsy y los gerentes de producto también codifican en varios niveles. Ops y dev trabajan muy de cerca, y tenemos un equipo de desarrollo que es muy operativo y se extiende a ambos dominios. Todos en la empresa usan IRC. Se elaboran muchas ideas en un wiki, y las personas de la empresa comentan sobre esas ideas y planes (utilizamos Confluence). Algunos proyectos se forman orgánicamente y otros son más descendentes.

Generalmente planificamos en partes de 60 días y dividimos los entregables en períodos de 2 semanas (aunque oficialmente no estamos usando capital-A Agile). El ciclo de 60 días no tiene un significado especial: simplemente sentimos que era un marco de tiempo razonable para planificar entregas a corto plazo. Los planes de 60 días pasan por una revisión, establecemos objetivos y publicamos los planes en la wiki. Nuestro fundador, CEO y jefe de producto (Rob Kalin) participa en estas revisiones y se mantiene en contacto cercano con los equipos de producto e ingeniería en todo momento. En general, los equipos tienen mucha autonomía en cómo realizan su trabajo dentro de un conjunto de principios arquitectónicos que hemos establecido (un tema para otra publicación) y nuestro enfoque de diseño general. Las especificaciones suelen ser muy ligeras, y la atención se centra en crear funciones de trabajo.

Incorporamos ingenieros rápidamente y su primer objetivo es simple: implementarlo en su primer día. El objetivo aquí es enfatizar constantemente el envío y superar pronto cualquier temor de implementación. Los ingenieros se vuelven productivos muy rápidamente. El nivel de cooperación entre desarrolladores y operaciones también es realmente alto (consulte nuestro blog de ingeniería para obtener más información: http://etsy.me/hMtu1A)

Practicamos la implementación continua y hacemos pequeños cambios con frecuencia en el sitio. Usamos lo que llamamos “banderas de configuración”, que son más o menos una copia exacta de lo que hace Flickr (vea el blog de ingeniería de Flickr: http://code.flickr.com/blog/2009…) y gran parte del código para funciones se ejecuta “oscuro” durante días o semanas, y el lanzamiento de funciones significa activar un interruptor en el código. Tenemos mucho ADN de Flickr en la empresa (John Allspaw, nuestro vicepresidente de operaciones, dirigió operaciones en Flickr, y Kellan Elliott-McCrea, nuestro vicepresidente de ingeniería, fue arquitecto en Flickr). En enero (un mes en el que realizamos más de mil millones de visitas), el código comprometido por 76 personas únicas fue implementado en producción por 63 personas diferentes, un total de 517 veces. Los gerentes de producto hacen cambios y realizan implementaciones (aquí está Jenn Vargas, uno de nuestros gerentes de producto más nuevos, tuiteando al respecto: http://twitter.com/jennjenn/stat…) y hemos capacitado a desarrolladores aspirantes en nuestro equipo de soporte para realizar pequeños cambios. con nuestra ayuda y orientación también. Nuestro entorno de implementación requiere mucha confianza, transparencia, comunicación, coordinación y disciplina en todo el equipo. Hemos invertido mucho en nuestra unidad automatizada y pruebas funcionales (tenemos un equipo dedicado exclusivamente a esto), herramientas para la implementación (vea nuestra publicación de blog sobre Deployinator: http://etsy.me/c6RJD7), y métricas y monitoreo (consulte “Seguimiento de cada versión”: http://etsy.me/e1ULhO). Las métricas clave a nivel de sistema y de negocio (como las tasas de pago / listado / registro / inicio de sesión) se proyectan en las pantallas de la oficina (http://www.flickr.com/photos/cha…) y tenemos una serie de paneles internos que utiliza el equipo (principalmente utilizamos Ganglia y Graphite). También tenemos muchos interruptores y perillas que nos ayudan a desplegar características a porcentajes de usuarios y aumentarlas lentamente o rápidamente. Usamos y probamos las características aquí en Etsy durante un período de tiempo antes de que se implementen públicamente.

Cuando cometemos errores, realizamos autopsias sin culpa y asignamos elementos de remediación a los miembros apropiados del equipo. Los ingenieros publican frecuentemente en nuestros foros de la comunidad cuando tenemos algún problema y tenemos un blog de estado que mantenemos (http://www.etsystatus.com/). Creo que interactuar con los miembros de Etsy les da a todos un sentido más profundo de responsabilidad por el código que estamos escribiendo. También escribimos sobre los errores que cometemos abiertamente (http://etsy.me/hgZ4qh).

En general, los ingenieros son tratados como colaboradores creativos en el proceso general con el diseño y el producto, y los productos son elaborados e iterados con los ingenieros en lugar de simplemente ser entregados a ellos para su implementación. A Rob (nuestro fundador y jefe de producto) le gusta trabajar con ingenieros y los ingenieros pasan mucho tiempo interactuando con Rob. Nuestra capacidad para trabajar de esta manera tiene tanto que ver con las personalidades de las personas involucradas y la cultura como las tecnologías involucradas. Siempre estamos aprendiendo y ajustándonos y seguiremos evolucionando a medida que pase el tiempo.