Close

DevOps: cómo romper la barrera entre Desarrollo y Operaciones

Ilustración del bucle de Devops

¿Qué es DevOps?

DevOps es un conjunto de prácticas que automatizan e integran los procesos entre los equipos de desarrollo de software y de TI para que puedan compilar, probar y publicar software con mayor rapidez y fiabilidad. El término DevOps se ha creado combinando las palabras “development” ('desarrollo' en inglés) y “operations” ('operaciones') y constituye un cambio cultural que salva la distancia que tradicionalmente separaba a los equipos de desarrollo y operaciones. 

Rueda en forma de símbolo de infinito de DevOps de Atlassian

En esencia, DevOps es una cultura, un movimiento, una filosofía.

Es un firme apretón de manos entre Desarrollo y Operaciones que pone de relieve un cambio de mentalidad, una mejor colaboración y una integración más sólida. Aúna la metodología ágil, git, la entrega continua, la automatización y mucho más, para que los equipos de desarrollo y operaciones sean más eficientes, innoven antes y aporten más valor a los negocios y los clientes.


DevOps no es el trabajo de una persona sola. Es el trabajo de todos.

Christophe Capel
Gestor de productos principal, Jira Service Desk

Logo de Chef.io

¿Quién utiliza DevOps?

Chef es la compañía que está detrás de la plataforma Chef Automate para flujos de trabajo de DevOps. Decenas de miles de desarrolladores utilizan Chef para probar, automatizar y gestionar infraestructuras. Situada al frente de la evolución de DevOps, la empresa, con sede en Seattle, ha publicado productos como Chef, InSpec, Habitat o Chef Automate para hallar nuevas formas de desarrollar y lanzar software y aplicaciones. Chef confía en la plataforma de Atlassian para experimentar con sus propias prácticas de DevOps y perfeccionarlas.

Historia de DevOps

El movimiento DevOps empezó a fraguarse entre el 2007 y el 2008, cuando las comunidades de las operaciones de TI y de desarrollo de software manifestaron claramente lo que veían como un nivel fatal de disfunción del sector.

Se alzaron contra el modelo tradicional de desarrollo de software, que exigía que los que escribían el código se mantuvieran al margen, en términos de organización y operación, de los que implementaban y mantenían dicho código.

Los desarrolladores y los profesionales de TI o de operaciones tenían objetivos distintos (y, a menudo, contrapuestos), direcciones de departamento independientes, indicadores clave del rendimiento diferentes por los que se les evaluaba y, con frecuencia, trabajaban en plantas separadas o, incluso, en edificios separados. El resultado eran equipos aislados únicamente preocupados por sus propios dominios, largas jornadas, publicaciones chapuceras y clientes insatisfechos. Tiene que haber un método mejor, dijeron. Así pues, las dos comunidades se juntaron y se pusieron a hablar, con personas como Patrick Dubois, Gene Kim y John Willis al frente de la conversación.

Lo que empezó en foros de internet y reuniones locales es ahora uno de los aspectos principales del ámbito del software actual, y seguramente lo que te ha traído hasta aquí. Tú y tu equipo estáis sufriendo el dolor causado por equipos encasillados y líneas de comunicación rotas dentro de la empresa.

Estás utilizando metodologías ágiles en la planificación y el desarrollo, pero te sigue costando sacar ese código sin montar un drama. Seguro que has oído hablar del modelo DevOps y el efecto aparentemente mágico que puede causar en los equipos: casi todos los equipos de DevOps (el 99 %) se mostraron seguros del éxito del código que estaban produciendo en una encuesta de 500 profesionales de DevOps llevada a cabo por Atlassian¹. 

Sin embargo, DevOps no es mágico, y los cambios no se dan de la noche a la mañana. Lo bueno es que no hay que esperar a que la alta dirección lance una iniciativa a gran escala. Teniendo en cuenta el valor de DevOps e implantando pequeños cambios de forma gradual, tu equipo se puede embarcar en el viaje hacia DevOps inmediatamente. Veamos cada una de esas ventajas en profundidad.

En comparación con los altos ejecutivos, es más probable que los profesionales de DevOps, en la práctica, coincidan en que resulta difícil medir el impacto del progreso y el éxito de DevOps: el 62 % está de acuerdo con esta afirmación, frente al 46 % de los altos ejecutivos.

Encuesta de Atlassian a profesionales de DevOps

Ventajas

Icono de personas conectadas

Colaboración y confianza

Hemos llevado a cabo una encuesta que ha determinado que el factor clave para que un equipo de DevOps funcione correctamente es la colaboración. Crear una cultura de responsabilidad compartida, transparencia y feedback más rápido es la base de los equipos de DevOps de alto rendimiento. Según nuestra encuesta, la colaboración y la resolución de problemas constituyen los elementos más decisivos para que la cultura de DevOps tenga éxito. 

Normalmente, los equipos que trabajan en grupos aislados no se adhieren al “pensamiento sistémico” de DevOps. Este “pensamiento sistémico” consiste en ser consciente de que tus acciones no solo afectan a tu equipo, sino a todos los equipos involucrados en el proceso de publicación. La falta de visibilidad y objetivos compartidos se traduce en falta de planificación de dependencias, prioridades mal organizadas, acusaciones personales y una actitud de “no es problema mío”, lo que provoca una disminución de la velocidad y la calidad. DevOps es ese cambio de mentalidad con el que se tiene una visión holística del proceso de desarrollo y se rompe la barrera entre desarrollo y operaciones.

Icono de velocímetro

Publicaciones más rápidas y una forma de trabajar más inteligente

La velocidad lo es todo. Los equipos que practican el DevOps publican las entregas con mayor frecuencia, calidad y estabilidad.  

La falta de automatización en las pruebas y los ciclos de revisión ralentiza la publicación de producción, y un tiempo de respuesta insuficiente ante los incidentes fulmina la velocidad y la seguridad del equipo. Además, trabajar con herramientas y procesos variados aumenta los costes operativos, provoca cambios de contexto y frena el ritmo. Gracias a las herramientas que impulsan la automatización y los nuevos procesos, los equipos pueden aumentar la productividad y publicar con más frecuencia y menos disgustos.

Icono de ritmo cardíaco

Acelerar el tiempo de resolución

El equipo con el ciclo de feedback más rápido es el equipo que prospera. Con una transparencia total y una comunicación fluida, los equipos de DevOps reducen al mínimo el tiempo de inactividad y resuelven las incidencias más rápido.

Si las incidencias críticas no se solucionan con rapidez, la satisfacción del cliente se viene abajo. Las incidencias clave se escapan entre las fisuras a falta de una comunicación abierta, lo que provoca el aumento de la tensión y la frustración entre los equipos. Gracias a una comunicación abierta, los equipos de desarrollo y operaciones se vuelcan en las incidencias, corrigen los incidentes y desbloquean antes el canal de publicación.

Icono de herramientas

Mejor gestión del trabajo imprevisto

El trabajo imprevisto es una realidad a la que se enfrentan todos los equipos: una realidad que casi siempre repercute en la productividad del equipo. Con procesos establecidos y una definición clara de las prioridades, los equipos de desarrollo y operaciones pueden gestionar mejor el trabajo imprevisto, sin dejar de lado el trabajo planificado.

La transición y priorización del trabajo imprevisto entre distintos equipos y sistemas no es eficiente y distrae de las labores que se están llevando a cabo. Sin embargo, con una mayor visibilidad y una retrospectiva proactiva, los equipos pueden prever y compartir mejor el trabajo imprevisto.

Marco CALMS para DevOps

CALMS es un marco de trabajo que evalúa la capacidad de una compañía de adoptar los procesos de DevOps, además de una forma de medir el éxito mientras tiene lugar la transformación a este modelo. La sigla, acuñada por Jez Humble, coautor de “The DevOps Handbook”, significa:


Jersey icon

Cultura

DevOps no es solo un proceso o un enfoque diferente del desarrollo, sino que constituye un cambio de cultura. Y una parte muy importante de la cultura de DevOps es la colaboración. 

Todas las herramientas y automatizaciones del mundo no sirven para nada si los profesionales de desarrollo y de TI o de operaciones no trabajan juntos, porque DevOps no soluciona los problemas relacionados con herramientas, sino los problemas humanos. 

Piensa en DevOps como la evolución de los equipos de metodología ágil, pero con la diferencia de que las operaciones están ahora incluidas de forma predeterminada. Formar equipos con una orientación hacia los proyectos o los productos que sustituyan equipos basados en funciones es dar un paso en la dirección correcta. Incluye desarrollo, control de calidad, gestión de productos, diseño, operaciones, gestión de proyectos y cualquier otro conjunto de aptitudes que requiera el proyecto. En lugar de tener un equipo que se encargue de todo o de contratar a “profesionales de DevOps”, es más importante contar con equipos basados en los proyectos que puedan trabajar juntos en perfecta armonía.  

Pocas cosas fomentan tanto la colaboración como compartir un objetivo común y tener un plan para alcanzarlo juntos. En algunas compañías, cambiar de repente a equipos basados en proyectos resulta algo excesivo y precipitado, por lo que es mejor ir a paso lento. Los equipos de desarrollo pueden (y deben) invitar a los miembros adecuados del equipo de operaciones a unirse a las sesiones de planificación de sprints, las reuniones rápidas diarias y las demostraciones de sprints. Y, del mismo modo, los equipos de operaciones también pueden invitar a desarrolladores clave a sus reuniones, ya que esta es una forma ágil y orgánica de estar al tanto de los proyectos, las ideas y las dificultades de los demás. 

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? ¿El incidente se trata a toro pasado centrándose en corregir los procesos, en lugar de realizar acusaciones personales? Si la respuesta es afirmativa, es una buena señal de que tu equipo trabaja siguiendo la estructura de DevOps.

Ten en cuenta que las empresas de mayor éxito aprueban la cultura de DevOps en todos los departamentos y a todos los niveles del organigrama. Cuentan con canales abiertos de comunicación 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.

Ilustración de engranajes

Automatización

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 y, a continuación, de 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” del servidor entre entornos, lo que reduce o acaba con 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.

Icono de lean DevOps

Infalible

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.

Ruler illustration

Medición

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.

Icono de bocadillos de mensaje

Compartir

La antigua fricción entre los equipos de desarrollo y operaciones se debe en gran medida a una falta de puntos en común. 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. En DevOps gusta la idea de que las personas que compilan una aplicación se involucren también en su lanzamiento y ejecución.

Esto no quiere decir que contrates desarrolladores esperando directamente que también dominen las operaciones. Lo que significa es que Desarrollo y Operaciones se unan en todas las fases del ciclo de vida de la aplicación.

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.

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.

La implementación de DevOps no es coser y cantar. Sin embargo, si cuenta con las herramientas, el marco de trabajo y el esfuerzo adecuados, una organización puede llevar a cabo una transformación al modelo DevOps que ofrezca ventajas significativas. 

Ponte en contacto con press@atlassian.com para obtener más información sobre la encuesta, llevada a cabo en colaboración con Cite Research.

¿Estás listo para emprender el viaje de DevOps?