Marco CALMS

Los desafíos e, incluso, las emergencias constituyen una prueba efectiva de la cultura de DevOps. ¿Se vuelcan los profesionales de desarrollo, operaciones y atención al cliente en el problema y lo resuelven como equipo? ¿Los análisis retrospectivos de incidentes se centran en mejorar los resultados para el próximo incidente en lugar de buscar culpables? Si la respuesta es "sí", es un buen indicio de que tu organización está adoptando una cultura de DevOps.

Las empresas de mayor éxito aprueban la cultura de DevOps en todos los departamentos y a todos los niveles del organigrama. A una escala tan amplia, el término "DevOps" suele quedarse corto y acabar por no ser necesario. Esas empresas cuentan con canales de comunicación abiertos y los emplean habitualmente. Asumen que mantener al cliente satisfecho es tanto responsabilidad de la gestión de productos como del equipo de desarrollo. Entienden que DevOps no es el trabajo de un solo equipo. Es el trabajo de todos.

La automatización contribuye a suprimir el trabajo manual repetitivo, genera procesos reproducibles y crea sistemas fiables.

Compilar, probar, desplegar y automatizar son los puntos de partida típicos de los equipos que aún no la han puesto en práctica. Oye, ¿y qué mejor motivo para que Desarrollo, Pruebas y Operaciones trabajen juntos que construir sistemas que los beneficien a todos?

Los equipos con escasa experiencia en automatización suelen empezar con la entrega continua: la práctica de ejecutar cada cambio en el código mediante un puñado de pruebas automatizadas, a menudo facilitadas por una infraestructura basada en la nube, para luego empaquetar compilaciones satisfactorias y promoverlas hasta producción con implementaciones automatizadas.

¿El motivo? Los ordenadores ejecutan las pruebas con mayor rigor y exactitud que los seres humanos. Estas pruebas detectan antes los errores y los fallos de seguridad. Además, las implementaciones automatizadas alertan a los equipos de TI y operaciones de los "desajustes" entre entornos, lo que reduce las sorpresas cuando llega la hora de publicar.

Otra de las contribuciones principales de DevOps es la idea de “configuración como código”. Los desarrolladores procuran crear aplicaciones modulares que admitan composición porque son más fiables y fáciles de mantener. La misma filosofía se puede aplicar a la infraestructura que las aloja, ya esté en la nube o en la red de la propia compañía.

La “configuración como código” y la “entrega continua” no son los únicos tipos de procesos automatizados que se observan en el mundo de DevOps, pero merecen una mención especial porque ayudan a derribar la barrera que hay entre el desarrollo y las operaciones. Y cuando DevOps utiliza implementaciones automatizadas para enviar código probado a conciencia a entornos de idéntica provisión, el “¡A mí me funciona!” deja de ser un mantra.

Cuando se habla de "lean" en un contexto de software, solemos pensar en suprimir actividades de escaso valor y avanzar rápido: ser enérgico, ser ágil. Más oportunos aún para DevOps son los conceptos de mejora continua y aceptación de los errores, que sientan las bases de una mentalidad experimental.

Una mentalidad de DevOps ve oportunidades de mejora continua en todas partes. Algunas resultan obvias, como mantener retrospectivas periódicas para mejorar los procesos del equipo. Otras son más sutiles, como las pruebas A/B en distintos métodos de incorporación para nuevos usuarios del producto.

Al desarrollo ágil le agradecemos el haber convertido la mejora continua en una idea corriente. Los primeros en adoptar la metodología ágil demostraron que un producto sencillo en manos de los clientes hoy tiene más valor que un producto perfecto en manos de los clientes dentro de seis meses. Si el producto se mejora continuamente, los clientes no se marcharán.

¿Y sabes qué? Cometer errores es inevitable. Así que es como si prepararas al equipo para asumirlos, recuperarse y aprender de ellos (algunos lo llaman “ser antifrágil”). En Atlassian pensamos que, si no te equivocas de vez en cuando, es que no te estás esforzando lo suficiente.

En el contexto de DevOps, equivocarse no es un delito punible. Los equipos tienen asumido que las cosas están destinadas a torcerse en algún momento, así que trabajan para conseguir detecciones y recuperaciones rápidas. Los análisis retrospectivos se centran en descubrir en qué fallaron los procesos y cómo reforzarlos, no en qué miembro del equipo se cargó el código. ¿Por qué? Porque la mejora continua y el fracaso van de la mano.

Sin datos, es difícil demostrar que tu esfuerzo continuo por mejorar esté en realidad mejorando algo. Por suerte, hay un montón de herramientas y tecnologías para medir el rendimiento: cuánto tiempo pasan los usuarios con tu producto, si esa entrada del blog ha generado alguna venta o con cuánta frecuencia aparecen alertas críticas en tus registros.

Aunque se puede medir casi todo, eso no quiere decir que lo tengas que medir todo. Sigue el ejemplo del desarrollo ágil y empieza por lo básico:

¿Cuánto tiempo se tardó en pasar del desarrollo a la implementación?

¿Con qué frecuencia tienen lugar errores o fallos?

¿Cuánto se tarda en recuperarse tras un fallo del sistema?

¿Cuántas personas utilizan su producto en este momento?

¿Cuántos usuarios has ganado o perdido esta semana?

Sobre una base sólida implantada, cuesta menos detectar métricas más sofisticadas del uso de las funciones, el recorrido de los clientes, y los acuerdos de nivel de servicio (SLA). La información que se obtiene viene muy bien a la hora de confeccionar hojas de ruta y especificar el siguiente gran paso.

Con todos estos datos jugosos, tu equipo puede tomar decisiones, pero resultan aún más útiles cuando se comparten con otros equipos, sobre todo si son de otros departamentos. Por ejemplo, el equipo de marketing quiere tener funciones nuevecitas que vender. Mientras tanto, observas una alta rotación de clientes, porque el producto está plagado de deuda técnica. Al aportar datos de los usuarios útiles para la hoja de ruta, aunque no profundicen en funciones y sí en correcciones, es más fácil lograr consenso y obtener la aceptación de las partes interesadas.

Por mucho que nos gustaría que existiera una varita mágica para transformar a todos los equipos en equipos de alto rendimiento de DevOps, la realidad es que la transformación a este modelo requiere una mezcla de prácticas, filosofías culturales y herramientas. Pero, como has leído, las ventajas que presenta terminar con la división de los equipos de desarrollo y operaciones merecen mucho la pena: mayor confianza, publicaciones de software más rápidas, implementaciones más fiables y mejor ciclo de feedback entre los equipos y los clientes.

Adoptar el modelo DevOps no es tarea fácil. Sin embargo, si cuenta con las herramientas, la mentalidad y el esfuerzo adecuados, una organización puede llevar a cabo una transformación al modelo DevOps que ofrezca ventajas significativas.

La antigua fricción entre los equipos de desarrollo y operaciones se debe en gran medida a una falta de intereses comunes. Creemos que compartir responsabilidades y logros representará un importante avance para zanjar esa división. Los desarrolladores pueden ganar puntos de buena voluntad de manera instantánea ayudando a soportar una de las cargas más pesadas del equipo de operaciones: el guion (hoy en día, en sentido figurado). En DevOps gusta la idea de que las personas que compilan una aplicación se involucren también en su lanzamiento y ejecución.

De esta idea surge la frase "tú lo creas, tú lo gestionas", que fomenta un enfoque práctico en todos los equipos. Esto no quiere decir que contrates desarrolladores esperando directamente que también dominen las operaciones. Lo que quiere decir es que los equipos de desarrollo y operaciones trabajan conjuntamente a lo largo de todo el ciclo de vida de una aplicación. Asimismo, los informes han demostrado que la única forma de revisión que mejora la entrega y el rendimiento es que los compañeros se revisen el código y los productos entre ellos. De hecho, apenas había diferencias entre externalizar las revisiones y no revisar.

Los equipos que adoptan DevOps suelen tener una función rotativa en la que los desarrolladores tratan las incidencias detectadas por los usuarios finales, mientras que solucionan problemas de producción al mismo tiempo. Esta persona da respuesta a las incidencias urgentes que los clientes han notificado, creando parches cuando haga falta, y trabaja en el backlog de los defectos notificados por clientes. El “desarrollador de apoyo” aprende así mucho sobre el uso que se le da a la aplicación en la vida real. Y gracias a su gran disponibilidad para con el equipo de operaciones, los equipos de desarrollo fomentan la confianza y el respeto mutuo.

Atlassian ha creado Open DevOps para que los equipos creen la cadena de herramientas de DevOps que quieran con las herramientas que les encantan gracias a las integraciones con los principales proveedores y aplicaciones de Marketplace. Pruébalo gratis ahora.