search
top

Vayamos al grano, ¿qué es eso de DevOps?

Ayer nos reunimos desde el meetup de Management 3.0, y tengo que decir que como siempre fue una experiencia genial.

Para este día, propusimos dividirnos en dos grupos y por un lado debatir sobre motivación y coaching y por otro sobre DevOps (o cómo romper barreras entre desarrollo/sistemas/negocio).

En mi caso, estuve en la parte de DevOps, y hablamos desde temas básicos como aclarar qué es DevOps, hasta si DevOps tiene sentido en todas las empresas o cómo ir tendiendo hacia esa cultura.

Por eso hoy me gustaría resumir los temas que tocamos ayer y las conclusiones que sacamos, ya que fueron unas horas muy interesantes.

Y bueno, también es cierto que en las cañas de después me comprometí a sacar las conclusiones a las 8 am del día siguiente, jeje.

¡Empecemos!

1 – ¿Qué es eso de DevOps?

DevOps es un término que engloba un grupo de conceptos, prácticas y técnicas que aunque no son todos nuevos, se están extendiendo por la comunidad del software.

Tal y como comentaba Javier hace unos días (El desarrollo software… se mueve por modas), es cierto que se escucha hablar de DevOps. Parece que está de moda, pero no todo el mundo sabe realmente lo que es.

DevOps sigue manteniendo la idea ágil de que las personas están por encima de los procesos y herramientas. Lo que queremos ahora es fomentar una cultura de equipo, una cultura de empresa a distintos niveles donde haya un poco más de transparencia y que por ejemplo gente de desarrollo sepa lo que hace sistemas y viceversa, negocio tenga más visibilidad sobre ciertos temas de desarrollo (por ejemplo cuándo va a salir una funcionalidad que ellos esperan, ¿está probada ya en QA? ¿por qué se ha tirado esa funcionalidad para atrás? ¿estáis teniendo problemas para subir a producción?) etc.

En definitiva, promover una cultura de romper barreras entre departamentos y fomentar un poco más la visibilidad y empatía entre las distintas áreas y en distinto grado (obviamente a alguien de negocio por ejemplo no le interesa algo super técnico).

Y optimizar el proceso de desarrollo para poder reducir los tiempos de paso a producción, de entrega al cliente.

Para conseguir ese objetivo se utilizan prácticas o herramientas relativamente nuevas, como por ejemplo el tema de tener “infraestructura como código”, con herramientas como Puppet o Chef ( Simplifica drásticamente la administración de sistemas: Puppet en 10 min.), para optimizar y facilitar ciertas tareas de sistemas.

Y otras no tan nuevas, como la integración continua (que nos ayuda muchísimo a mejorar la calidad tanto del proceso como del producto que desarrollamos), y si llegamos, la entrega y despliegue continuos.

1.1- ¿Entonces existe un rol de DevOps?

No. DevOps como tal no es una persona, es más una cultura y la utilización de una serie de principios, herramientas y prácticas para lograr ese objetivo de romper barreras entre departamentos y crear una cultura de empresa, de equipo a distintos niveles.

Erróneamente se considera “un DevOps” a alguien de la parte de sistemas que esté más interesado en temas como virtualización, orquestación, monitorización, integración continua y demás, pero DevOps como tal no es un rol.

Por llevarlo a algo conocido, ¿si tienes un tablero Scrum significa que tu empresa es ágil? ¿O si usas Planning Poker automáticamente eres ágil? No, son una serie de piezas intermedias para conseguir llevar a la práctica los valores y principios ágiles.

Lo mismo pasa con DevOps. Tener integración continua, tener virtualizados los entornos etc., no implica ser DevOps, pero ayuda a ese fin.

De hecho todas estas prácticas existían antes de acuñar el término DevOps.

2 – ¿Y por qué me dices que DevOps rompe barreras también entre negocio y el resto de áreas?

Porque primero, damos visibilidad al proceso de desarrollo, se vuelve más transparente.

Por ejemplo, podemos ver desde el servidor de integración continua las diferentes etapas por las que va pasando el software. Puedes ver si algo ha fallado, si todo ha ido bien. Puedes acceder a ver las métricas de calidad de código, ver los resultados de las pruebas etc.

Por otro lado, ¿cuánto tardo en subir código nuevo a producción? Y ojo que aquí no hablo de entrega y despliegue continuos.

Si hago un paso a producción y hay un fallo grave, ¿cuánto tardo en volver a restaurar la versión anterior? ¿O volver a subir una solución nueva? En cierto tipo de empresas software es inviable tener caídas del software por mucho tiempo.

Con un buen entorno de integración continua y/o con un buen proceso de desarrollo optimizado, conocido y fiable, puedo llegar a pasar a producción funcionalidades con mayor frecuencia.

3 – ¿DevOps tiene sentido en todas las empresas? ¿O es solo para empresas ágiles?

Aquí comentábamos que sí que creemos que lo que promueve DevOps sea beneficioso para todas las empresas software, de hecho, es algo que tiene mucha lógica.

No obstante pensamos que no es igual de sencillo en todas las empresas, ya que conlleva un cambio cultural muy fuerte.

A empresas muy tradicionales, con procedimientos muy firmes (ej: rellenar un papel para pedir desplegar a un entorno, y que te contesten a los X días cuando el software que querías subir se ha quedado desactualizado porque habéis solucionado errores e implementado nueva funcionalidad…) les costará más.

Por otra parte creemos que hay empresas que por su naturaleza, por su negocio, tenderán solas a una cultura de este tipo. Una startup, una empresa de producto, necesita moverse muy rápido y responder al cambio, y DevOps es muy bueno para ello.

4 – ¿Cómo convencer a la dirección para implantar prácticas y tender a la cultura de DevOps?

Aquí hablamos de una cosa que me gustó mucho. Tu empresa necesita DevOps porque reduce costes, porque tener una cultura de DevOps aporta a tu empresa una ventaja competitiva.

Todos queremos tener las cosas rápido, barato y con buena calidad. Muchos proyectos irán a hacer las cosas rápido, barato y mal, y eso al final se acaba notando.

¿Cómo podemos competir contra eso? ¿Cómo podremos llegar competir contra un desarrollo en India, a precios más baratos? (Y no tengo nada contra la India, pero salió este ejemplo)

Pues optimizando nuestros procesos, aumentando nuestra calidad, y aprovechando ese tiempo que ganamos para sacar las cosas más rápido, pero bien.

Además de que poco a poco reducimos los fallos de nuestra aplicación o respondemos más rápido ante ellos. Un fallo en producción cuesta mucho dinero, tenemos que intentar que el software llegue lo mejor posible a producción.

5 – Vale, los he convencido ¿Y cómo empezamos? ¿Qué obstáculos me encontraré y cómo superarlos?

En este punto nos poníamos en el caso de que íbamos a implantar DevOps en cualquier empresa software. ¿Qué impedimentos podríamos encontrarnos?

Lo primero que comentamos fue la negativa de la dirección, que se sienta atacada ante una visión un poco más transparente en la que pierda cierta parte de control. Lo cierto es que DevOps no significa adiós dirección, adiós sistemas, bienvenido al mundo de los desarrolladores que toman el control. Hay un orden.

Significa más visibilidad, más cooperación entre las áreas, que al final están trabajando para un objetivo común.

Otro obstáculo relacionado con el anterior es el cambio de mentalidad que conlleva DevOps. Y es cierto.

En mi experiencia, no hay nada mejor para demostrar que algo puede funcionar que ponerse a ello. Poco a poco, implantarlo paulatinamente, pero que la gente vea que se van consiguiendo cosas. Que no solo es teoría bonita.

Poneos etapas. Detecta fallos en tu proceso de desarrollo. Plantéate qué optimizar. Cómo resolver problemas de comunicación. Y ve dando pequeños pasos.

Normalmente veo que la gente no se cree que la integración continua pueda llegar aplicarse en su empresa. Perfecto, es normal, muchas decepciones, vamos poco a poco.

Optimicemos esto por aquí, automaticemos despliegues por allá. Con cada etapa que vamos avanzando el objetivo final está más cerca, y los reticentes se van convenciendo más.

Obviamente no todo es de color de rosa. Saldrán problemas. Pero se hace camino al andar.

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

3 Respuestas to “Vayamos al grano, ¿qué es eso de DevOps?”

  1. mruiz dice:

    Poneos etapas. Detecta fallos en tu proceso de desarrollo. Plantéate qué optimizar. Cómo resolver problemas de comunicación. Y ve dando pequeños pasos.

    Me quedo con esta recomendación a la que si añadimos la eliminación de la “basura” en la optimización de los procesos nos encontrariamos con la agilidad que nos da LEAN.

    Gracias por las aclaraciones sobre DevOps, cuando algo se pone de moda es fácil perder el foco en la idea principal pero esta claro que la tendencia deberia ser esta en los distintos departamentos de IT.

  2. Milo dice:

    Buenisimo tu blog, te sigo desde Chile.
    Trabajo para una multinacional grande de Telco y estamos comenzando con nuestros primeros pasos hacia devops. Creo que lo más complejo en mi caso de cambiar, es la mentalidad de las otras áreas. La política es muy fuerte en empresas grandes, por lo que “mantener tu parcela” es un dogma difícil de romper. Por suerte podemos experimentar, e intentar demostrar lo beneficioso que es para la empresa.
    Por desgracia o suerte, debemos experimentar con las herramientas IBM, en este caso con su compra reciente, urban code. La desgracia es que la consultoría de apoyo es pésima. La suerte es que habíamos visto el producto antes. Es un largo camino y creo que merece más entradas. Hoy día nadie tiene la panacea, y no creo que llegue a existir, hay demasiadas variables en cada compañía, pero creo que hay pasos que serán comunes para todos.

  3. Jesús Villacañas Sánchez-Mellado dice:

    Veo que para hacer esto hay que cambiar totalmente la cultura de la empresa. Estoy de acuerdo que resultará más ágil, pero se están asumiendo más riesgos, no pasar un cambio por un CAB, puede ocasionarnos un problema por que posiblemente no veamos siempre todas las implicaciones de dicho cambio (como cambio incluyo las subidas a producción) en todos sus aspectos.

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top