Desarrollando software a la Prey. Episodio 1.
En el artículo anterior les contamos cómo estructuramos y desarrollamos nuestra Infraestructura para 10 millones de dispositivos. Ahora, nos gustaría contarles sobre cómo abordamos el desarrollo de software interno en Prey.
SCRUM
En Prey utilizamos casi todas las actividades y artefactos definidos por SCRUM. Escribo casi, porque como cualquier metodología de buenas prácticas, tomamos lo que mejor nos sirve y desechamos lo que no. En nuestro artículo Hola Mundo, en Español Chileno describimos cómo se estructura el equipo para nuestra implementación de SCRUM.
Match Técnico
Todo nuevo sistema, componente, servicio o aplicación comienza con una discusión técnica con los miembros del equipo interesados. Esta reunión, generalmente improvisada, la hacemos, curiosamente, en una sala de reuniones, con pizarra a mano. Dibujamos la idea general y los requerimientos principales. Discutimos y peleamos hasta llegar al momento Zen, que corresponde a aquél instante en que todos los interesados entienden el problema y la posible mejor solución. Desde ese momento en adelante, naturalmente surge un responsable técnico, que trabajará en el proyecto hasta el momento que se pone en producción.
Arquitecturando™
Algunos proyectos cuentan con un Documento de Diseño que describe el problema y solución de forma general. Los documentos se escriben y revisan de forma colaborativa usando Google Docs.
En este documento, se describen los siguientes puntos:
- Resumen: Corresponde a UN PÁRRAFO resumiendo el contenido del documento. Debería dar a entender rápidamente el alcance de la solución.
- Descripción: En esta sección se describen de forma general las principales estructuras de datos y algoritmos. A veces, se incluye información adicional, como definiciones de servicios RPC o modelos de datos, por ejemplo. Como regla de oro, debería incluir toda la información necesaria para armar un mapa mental de la solución completa.
- Implementación Técnica: La salsa secreta de cómo se llevará a cabo la solución. Aquí se describen las librerías, los lenguajes, los cálculos, las fórmulas, las implementaciones de las clases, estructuras y algoritmos.
- Referencias: Valoramos enormemente que nuestras soluciones se inspiren en referencias académicas o de terceros, por lo que en esta sección se enumeran todos los recursos y referencias bibliográficas que sean necesarias.
Algunos proyectos también utilizan el tradicional “bosquejo de alto nivel” que nos permite tener una hoja de ruta que va madurando día a día en la medida que se avanza sobre la solución.
Prueba de Concepto (POC)
En varios proyectos se implementan Pruebas de Concepto inmediatamente después de que el Documento de Diseño haya sido revisado por al menos un miembro del equipo técnico.
Las POC se prueban en ambientes de Staging o Canary:
- Staging es la representación más clásica del concepto, en nuestro caso, corresponde a la infraestructura donde probamos todos los cambios de la aplicación web de Prey.
- Canary es un entorno de producción (con acceso a componentes de producción) que no se expone directamente a tráfico público, aquí es donde se prueban los nuevos servicios y micro-servicios.
En el entorno que corresponda, realizamos pruebas sintéticas verificando la capacidad del servidor dentro de una instancia tipo (4 CPU y 8 GB de RAM).
El resultado de una Prueba de Concepto exitosa es cuando se verifica la hipótesis principal descrita por el Documento de Diseño. Por ejemplo, en el documento de Notify (nombre código para el sistema descrito en nuestro artículo anterior), una de las hipótesis era que un servidor sería capaz de alcanzar 150.000 conexiones concurrentes. En la figura se observan los resultados para una prueba sintética, verificando que cada servidor era efectivamente capaz de alcanzar casi 150.000 conexiones concurrentes.
Desarrollo 1.0
En esta etapa se desarrolla la versión 1.0 del sistema. Esto puede tomar días, semanas o incluso meses, y en todo el transcurso de este desarrollo cuidamos la calidad del trabajo versus el tiempo. Por ejemplo, la nueva versión de Prey tomó más de 2 años en desarrollarse (ni se imaginan la celebración una vez estuvo en producción).
De a poco hemos ido estructurando nuestra base de código en múltiples repositorios que juntos conforman una base de código unificada y centralizada.
La principal ventaja de esta estructura es que distintos sistemas y servicios pueden reutilizar código de otros sistemas. Por ejemplo, todos los servidores web importan code.preyinternal.com/prey/net/frontend/health, que agrega un sistema de Revisión de Salud en la URI /healthz para que los balanceadores puedan redirigir tráfico en caso de que un servicio muera misteriosamente.
Revisión de Código
Todo el código de Prey es revisado por pares. Todo el código de Prey tiene pruebas de unidad ¹. Sin excepciones.
Si se necesitan introducir cambios a cualquier repositorio, se debe generar un control de cambios sobre una rama originada desde master. Una vez que los cambios estén listos y verificados por Control de Calidad (QA), se genera un Pull Request (PR) que debe ser revisado por miembros del equipo con conocimientos de escritura y lectura en los distintos lenguajes que sean usados en el PR. En el mismo PR se agregan observaciones de código, comentarios técnicos y preguntas de producto. Una vez que el set de cambios se declara “estable” se realiza una última revisión de código. Los responsables de cada PR declaran LGTM ² una vez que todas las observaciones han sido resueltas.
Al mismo tiempo en que un PR es aprobado, se ejecutan automáticamente todas las pruebas de unidad a través de un sistema de Integración Continua interno basado en el núcleo de TravisCI: PerkinsCI.
En la medida que todas las pruebas pasen, se introducen los cambios a master y se agenda la puesta en producción.
Puesta en Producción
Poner en un servicio en producción debería ser tan simple como escribir cap production deploy o houston control update en una terminal con privilegios.
Sin embargo, todo nuevo sistema debe cumplir con una rigurosa revisión de distintos componentes y elementos que el equipo de Infraestructura supervisa para mantener una plataforma estable, siempre apuntando a la disponibilidad 99.99% ³.
Aprendizajes
Lo malo: Como en todo ecosistema, siempre cometeremos errores en cualquier proceso, por lo que el aprendizaje a partir del error es tremendamente valorado, inclusive en aquellos momentos que hemos llegado a perder plata o bloqueado la base de datos de producción. Creemos FUERTEMENTE en no apuntar con el dedo ni pensar que nunca cometeremos errores. Lo que no significa que no seamos rigurosos con cuándo cometemos errores… por lo que si alguien se manda una embarrada, le toca escribir el Post Mortem.
Lo bueno: Como muchas cosas en la vida, siempre podemos ir mejorando y ajustando partes de los procesos o ecosistemas, pero creemos que es mejor tener una buena base y poder aprovechar lo que sea necesario a que no tener ninguna base. Tiempo al tiempo y no-estructuras son nuestros secretos.
Recursos
PerkinsCI — por miguel michelson, nuestro sistema de integración continua disponible en GitHub.
¹ Si bien todo el nuevo código de Prey cuenta con pruebas de unidad, todavía contamos con una deuda técnica en cobertura de código, que intentamos disminuir cada vez que podemos.
² LGTM significa “Looks Good To Me”, conceptualizado por Google y ampliamente adoptado por la industria. https://www.quora.com/What-is-Googles-internal-code-review-policy-process
³ La revisión por listado fue introducida recientemente. La infraestructura global de Prey se separa en tres componentes conocidos como solid, panel y www, cuya disponibilidad es 99.94%, 99.91% y 99.99% respectivamente, para 2016, según pingdom.com.
¿Cómo desarrollan software en tu organización? ¿Qué podríamos mejorar de nuestro ecosistema?
