DevOps: ¿Cómo ha evolucionado? ¿Cómo se ha desvirtuado?

El término DevOps comenzó a sonar en nuestro sector en el año 2008. Desde un inicio, llegó para cambiar la forma en la que se desarrolla el software. Por suerte, lo hizo, y para bien, aunque al no tener unas bases claras establecidas fue tomando caminos diversos, que posiblemente no eran los que se pensaron en un principio.

Un tiempo después de sus orígenes (en el año 2015), mi compañero José Ruiz parece que se olía algo y escribió este post, en el que explica qué es DevOps (y sobre todo qué no es DevOps).

Han pasado 8 años desde aquel post. Desde entonces, este “movimiento” ha seguido expandiéndose y ayudándonos en nuestro día a día, pero como ocurrió en los primeros años, paralelamente se ha seguido desvirtuando.

Una vez dijo Antonio Gala: “Lo malo no es que los sevillanos piensen que tienen la ciudad más bonita del mundo… lo peor es que puede que tengan hasta razón”.

Yo pienso que los sevillanos tenemos razón, igual que pienso que no hay un club mejor que el Betis, pero entiendo que son opiniones y no tienen que ser compartidas por todo el mundo.

Lo mismo ocurre con el tema a tratar en este post y, por ello, quiero aclarar de antemano que todo lo hablado nace de mis experiencias y que al igual que ocurre con mi ciudad o mi equipo, no todo el mundo tiene por qué estar de acuerdo.

De conjunto de prácticas a uno de los perfiles más demandados

Ya hay mucho escrito sobre qué es DevOps y no quiero repetirme, pero creo que es importante revisar al menos su definición para poder dar ciertas explicaciones: “Conjunto de prácticas que agrupan el desarrollo de software (Dev) y las operaciones de TI (Ops) con el objetivo de hacer más rápido el ciclo de vida del desarrollo de software, proporcionando una entrega continua de alta calidad”.

Y digo yo, si son un conjunto de prácticas, ¿cómo es posible que entre en LinkedIn vea tantas personas que se definen como DevOps? ¿Cómo es posible que vea tantas ofertas demandando eso mismo? Esto se debe a lo que comentaba al inicio del post. Se ha ido desvirtuando a medida que iba expandiéndose.

Quizás yo sea muy purista, pero por más que conviva con ello sigo sin verlo como un perfil técnico. Independientemente de la definición originaria, la cual podría entender que haya evolucionado, pienso que ese “conjunto de prácticas” son tan amplias e incluyen una infinidad de herramientas en constante evolución, que es demasiado complicado que una sola persona domine.

¡Ojo! En el sector hay auténticos genios que posiblemente sí sean capaces, pero estoy seguro (porque me he encontrado muchos) que hay un porcentaje alto que se denominan DevOps pese a tener carencias de conocimientos muy básicas.

El perfil DevOps

Asumiendo que yo no voy a cambiar nada, vamos a describir los conocimientos que creo que tiene tener ese superhombre llamado DevOps.

Desarrollador

No, no tiene por qué ser un experto desarrollador, pero es uno de los valores principales. Tener una visión programática ayuda (y mucho) a la hora de afrontar distintos problemas y situaciones del día a día. Además, de esa llamada visión programática, los conocimientos en desarrollo son importantes por estos dos motivos:

• El primero es ser capaz de entender y lanzar las distintas fases del flujo para los principales lenguajes: compilación, instalación de dependencias, ejecución de tests, subía de artefacto... entre muchos otros. Para lanzarlas, también debe saber configurarlas, ya sean en un pom.xml, en un package.json o donde lo requiera la tipología del proyecto.
• El segundo es que los scripts no vienen en lata. Hay que saber desarrollar los pasos de un pipeline o de un script de despliegue de infraestructura, entre muchos otros.

QA

Aquí es donde me toca a mí más la fibra, ya que como QA me he encontrado con situaciones surrealistas. Me he encontrado con algunos DevOps que no saben qué es un test unitario. También he visto a algunos definir ciclos en los que las fases se lanzan en un orden que no tiene sentido, con los riesgos para el producto que eso implica.

Todo ello se debe a que no tienen las bases necesarias y, como decía antes, el tema de la calidad me duele especialmente. Por ello, diría que: “Si te autodenominas DevOps es porque entiendes y puedes automatizar todo el ciclo de vida del desarrollo de software y esto también implica TODO lo relacionado con la calidad del mismo”.

Al igual que ocurría en el punto anterior, tiene que ser capaz de entender, configurar y lanzar las fases “más relacionadas” con la calidad de software. Esto ya de por sí es un abanico muy amplio, que implicaría temas como:

• Disponer de conceptos de calidad de código que te pueden ayudar a saber cuándo bloquear una PR
• Entender los distintos tipos de tests para saber qué son y en qué momento aplican cada uno.
• Saber configurar herramientas como Sonar o Kiuwan para introducirla dentro del ya mencionado flujo

Estos eran solo unos pequeños ejemplos, aunque para mí hay algo mucho más importante y que no se aprende. La actitud crítica y perfeccionista para poder “sustituir” labores que hasta ahora realizaba el QA dentro de un proyecto.

Seguridad

La gran olvidada. Al igual que sin calidad no somos nada, sin seguridad estamos perdidos. La seguridad de una manera u otra aplica a prácticamente todas las fases del proyecto:

• Agujeros de seguridad en nuestro código, a lo cual también nos puede ayudar Sonar y Kiuwan.
• Control de vulnerabilidades en dependencias. Podéis ver aquí un ejemplo.
• Securización de herramientas e infraestructura.

Sistemas

De todos, este quizás sea el puesto que se ha visto más afectado por la aparición de este nuevo perfil. Hay expertos en sistemas que para no quedar descolgados del mercado laboral se han autodenominado “DevOps”, sin tener conocimientos de los tres puntos anteriores. Aunque bueno, también he visto QAs que han hecho dos cursos de AWS y tristemente se autodenominan igual.

Sistemas, de por sí, me parece ya bastante amplio y complejo, ya que implica muchos y variopintos temas y sobre todo muchas herramientas distintas según el ecosistema de cada proyecto.

Debe poder encargarse de la instalación, configuración, mejora y supervisión de toda la infraestructura del proyecto. Esta no solo aplica a los entornos de desarrollo, también aplica al entorno de producción, con la responsabilidad que ello conlleva.

¿Conoces a muchos DevOps que cumplan todo lo anterior? Pues es solo una parte, no he añadido temas como: versionado de código y política de ramas, administración y gestión de artefactos… entre otros muchos temas que también se verían implicados.

El círculo QSO en Paradigma

En Paradigma, al igual que ocurre en muchas empresas del sector, existen agrupaciones de personas con perfiles similares. He visto llamar a estos grupos de muchas formas: tribus, equipos, departamentos… Aquí los llamamos Círculos, en referencia a agrupaciones por círculos de conocimientos.

Hace tiempo se creó el Círculo de QSO, donde se juntaron los perfiles de QA, Sistemas, Seguridad y Operaciones. Ese círculo de conocimientos ha permitido que podamos apoyarnos y formarnos unos a otros en distintas áreas. Gracias a ello, proporcionamos una entrega continua, rápida, automatizada y de alta calidad en los distintos equipos de desarrollo. ¿Te suena?

Y tú ¿qué opinas?

Estamos llegando al final del post. En este punto, si piensas que Sevilla es la ciudad más bonita del mundo, que el Betis es el mejor club y que DevOps no debería considerarse como un perfil, ya tenemos tres cosas en común. Si piensas distinto, estoy seguro de que tienes tus motivos y que no te faltan razones.

Recuerda. Lo escrito en este post proviene de mis experiencias y en una definición de algo que apareció hace unos 15 años. ¿Qué quiero decir con esto? No te dejes llevar por las modas del sector: fórmate, investiga y gana experiencia para crear tu pensamiento propio.

"Caminar sobre el agua y desarrollar software a partir de una especificación es fácil si ambos están congelados", Edward V. Berard.