DevOps en GBH – ¿Cómo empezamos?

Para la unidad de Tecnología, no es en absoluto una tarea sencilla gestionar equipos y su trabajo. La gestión de las personas es una de las tareas más complejas que se pueden llevar a cabo; esto es especialmente cierto en el caso de los apasionados de la tecnología. Hay que reconocer que cada individuo es diferente, lo que hace casi imposible la tarea de diseñar un marco único para satisfacer sus necesidades de trabajo, e incluso si se consigue alcanzar una cierta comprensión y equilibrio en ese marco, los constantes cambios hacen que nuestra «comprensión» actual sea efímera.

Los jefes de los equipos de Tecnología deben ocuparse tanto de las necesidades de la empresa como de las de su gente. Se les asigna la tarea de ofrecer los mejores resultados posibles, al tiempo que mantienen una relación sana y equilibrada entre lo que hay que hacer y las personas que participan en su realización.

Hemos aprendido a lo largo de nuestra historia que centrarse en los objetivos del negocio (producción), más que en la mano de obra, es la fórmula perfecta para el fracaso; existe una profunda conexión entre la motivación y la apropiación de su equipo, y la calidad de los resultados que producen.

Cuando se habla de personas, el comportamiento de un individuo se ve profundamente afectado por el entorno en el que convive activamente, y es casi imposible de medir o predecir. He aquí una reflexión interesante: la informática, la industria en la que cada recurso construido está programado para hacer sólo aquello para lo que fue diseñado, funciona y ha evolucionado gracias a las personas que son, por diseño, impredecibles, en constante evolución y, en última instancia, extremadamente complejas. Llevamos mucho tiempo preocupándonos por la dificultad heredada de nuestros programas, aplicaciones y sistemas, retrasando la inevitable tarea de preocuparnos por nuestra propia complejidad, que a menudo afecta a la calidad de nuestros resultados.

Así, podemos llegar a una conclusión significativa: no podemos escapar de la complejidad de las personas, el negocio, la comunicación y la necesidad constante de mantenerlos a todos juntos en una caja y esperar que se lleven bien.

Las necesidades de las personas, los objetivos empresariales y las barreras de comunicación representan la relación más desequilibrada y disfuncional que jamás haya existido.

Pero hay buenas noticias. A lo largo de la historia del universo de las Tecnologías, se han diseñado e implementado muchas metodologías para mejorar la forma en que los equipos trabajan en cualquier conjunto de entregas, ya sea el desarrollo de un sistema, la implementación de un servidor o el eterno calvario de arreglar impresoras en la oficina. Se puede pasar de cualquier método de gestión de proyectos a una herramienta concreta, como un sistema de gestión de tickets, para abordar la complejidad de las tareas y los procesos y procedimientos de alto nivel necesarios para llevarlas a cabo.

Uno de los ejemplos recientes más populares de estas tecnologías de apoyo es el marco ágil, que es también el origen de nuestro tema principal para este artículo: DevOps.

En muchos artículos de Internet se dice que DevOps (entre otros temas más recientes del mundo de la informática) es una de las palabras de moda más famosas que han surgido. Para ser justos, si algo funciona, ¿para qué molestarse con palabras y conceptos rebuscados, verdad? Bueno, ciertamente fue mucho más que una simple palabra de moda porque ahora toda la ingeniería de software y la industria de Tecnologías buscan desesperadamente la implementación de DevOps en la cultura y los procesos de cualquier organización. ¿Por qué? ¿Cuál es el atractivo o la diferencia en comparación con otras metodologías que existen desde hace tiempo y son funcionales? ¿Será que este era el nudo que faltaba para atar de una vez por todas nuestra disfuncional familia de tres? La respuesta a esta pregunta es lo que llevó a nuestra organización, GBH, a empezar a prestar atención a esta «nueva forma» de hacer las cosas en las etapas iniciales de su apogeo.

Queremos mostrarte un poco de nuestro viaje y por qué, en GBH, amamos DevOps.

Antecedentes

[DevOps en el mundo]

¡DevOps! ¡Sí! Pero… ¿qué es DevOps, exactamente?

En la comunidad de desarrollo de software, no se puede escapar de DevOps. Ahora se ha convertido en uno de los activos más importantes del SDLC (ciclo de vida del desarrollo de software) de cualquier organización con actividades significativas de desarrollo de software. Entonces, ¿qué podemos decir al respecto?

Las definiciones de DevOps son un tópico a estas alturas porque, inmediatamente todo el mundo piensa en sus dos objetivos iniciales: Desarrollo y Operaciones. Para nosotros y para muchos, es más que eso: es la integración entre equipos que permite a una organización mejorar la forma en que Ágil debía ser, llenando los vacíos y centrándose en gran medida en la comunicación, la medición, la continuidad y las capacidades de autoservicio, y sobre todo, en las personas.

Los beneficios de incluir DevOps en todos los procesos y procedimientos ya no se subestiman. Muchos CTOs y Directores de Tecnología han comprobado de primera mano cómo puede mejorar la armonía de desplegar continuamente cambios en un sistema sin ninguna preocupación, garantizando además la disponibilidad, integridad, escalabilidad y fiabilidad de sus sistemas. Una cultura, una revolución que ha cambiado la Ingeniería del Software para siempre.

Sin embargo, nuestra organización sabía lo que DevOps podía aportar para convertirla en la mejor empresa de desarrollo de software de la región.

[El estado de DevOps en 2018]

Uno de los aspectos clave de DevOps es que no viene con un tutorial sobre cómo lograr el éxito en el desarrollo de software. Su implementación e importancia dependen en gran medida de la cultura y los medios de producción de la organización. Este pensamiento está respaldado por las principales conclusiones del informe Puppet State of DevOps Report of 2018. En este informe, se afirma que la implementación completa de DevOps en cualquier organización se puede dividir en 5 etapas: 

• Etapa 1: Normalizar la pila tecnológica.
• Etapa 2: Estandarizar y reducir la variabilidad.
• Etapa 3: Ampliar las prácticas DevOps.
• Etapa 4: Automatizar la entrega de la infraestructura.
• Etapa 5: Proporcionar capacidades de autoservicio.

Si su organización realiza el desarrollo de software en alguna capacidad y desea implementar la metodología DevOps, es necesario entender los principios básicos y la importancia de las etapas mencionadas.

La necesidad

¿Cuál fue el impulso que nos llevó a preocuparnos por una palabra de moda en la que sólo un puñado de personas confiaba? No fue porque las cosas no estuvieran funcionando ni aportando el valor que queríamos para nuestros clientes. Más bien fue porque comprendimos la importancia de mejorar lo que ya nos funcionaba para poder ofrecer un mejor servicio con un flujo de trabajo más racionalizado y estandarizado. No teníamos suficiente estandarización en nuestros múltiples entornos, todos los problemas se atacaban de forma reactiva, los procesos de integración y entrega se bloqueaban constantemente debido a la gran cantidad de trabajo manual y a la comunicación ineficiente entre los diferentes equipos. En resumen, había muchas cosas que sabíamos que podíamos mejorar, pero no sabíamos por dónde empezar – ahí es donde DevOps entró como una de las soluciones viables para nuestros dolores.

El papel

A pesar de que en la comunidad DevOps se dice que DevOps no es y no debe ser un «puesto», un «rol» o un «equipo», se convirtió en una práctica generalizada el dedicar un papel específicamente para hacer frente a algunos de los pilares clave de la metodología, así el rol de Ingeniero(ría) DevOps surgió. Seguimos esta convención no oficial y nuestro primer rol definido se convirtió en «Ingeniero de DevOps». Aunque al principio nos centramos en estandarizar los procesos de operaciones, conseguimos crear un marco capaz de transformar el ciclo de vida del desarrollo de software en un pipeline más flexible, mejorado y optimizado en general.

Aterricé en GBH en febrero de 2018 y, desde entonces, he estado participando en una de las organizaciones más orientadas a la cultura de la que he formado parte, desde mis inicios en el área de Tecnología cerca de 2015. GBH buscaba en ese momento un jefe de Ingeniería DevOps, pero, debido a la escasez y falta de candidatos para el rol, se decidió contratar a un ingeniero de nivel medio tipo DevOps y proporcionarle toda la formación necesaria para desempeñar el rol y lograr lo que se esperaba de él. En ese momento, era un Ingeniero de Sistemas con sabor a DevOpsy* ya que debía entender el funcionamiento de las aplicaciones en mayor medida que los habituales Ingenieros de Operaciones.

GBH se convirtió entonces en una de las primeras y pocas organizaciones en República Dominicana en 2018 con un rol DevOps en sus filas.

Nuestros primeros pasos

Nuestros primeros pasos en el viaje de DevOps se centraron en mejorar la incorporación de desarrollo. Teníamos casos en los que configurar todo para que el ingeniero de software realizara algún trabajo podía tomar hasta 1 semana – eso era insano considerando que nuestros principales recursos para la producción del negocio estaban estrechamente relacionados con la productividad del desarrollador. Hicimos una lluvia de ideas y finalmente llegamos a la conclusión de que el entorno de desarrollo era el punto de tensión por la cantidad de tiempo que se invertía en la incorporación. Para ello, optamos por crear un sistema que permitiera al desarrollador ejecutar un único comando en su máquina local y que aprovisionara todo lo necesario para empezar -al principio llamamos a este sistema «dockerizado», pero ahora ha evolucionado a DEMS (Sistema de gestión del entorno de desarrollo).

Con DEMS (que es una combinación de contenedores y scripts de shell), pudimos reducir el tiempo de desarrollo de una semana a menos de media hora. Eso fue 35 horas reducidas a un par de minutos – fue una gran victoria porque experimentamos de primera mano cómo DevOps podría mejorar no sólo el ya tedioso flujo de trabajo de establecer un entorno de desarrollo, sino todos los demás procesos que participan en el ciclo de vida del desarrollo. Suponíamos que DEMS era sólo el principio y, alerta de spoiler, lo era.

Mucho ha cambiado desde la concepción de DEMS; ahora tenemos múltiples integraciones que automatizan la comunicación entre los sistemas que soportan nuestras comunicaciones y la prestación de servicios. Incluyendo la implementación de pipelines CI/CD, la implementación y configuración de herramientas para mejorar la mentalidad de continuidad y las capacidades de autoservicio de nuestros equipos, la estandarización y la reducción de la variabilidad en los entornos y flujos de trabajo.

Dónde estamos ahora

Venimos de lejos, pero eso no significa que ahora estemos satisfechos (¡no creo que lo estemos nunca!) El mundo de las Tecnologías de la Información está en constante cambio y mejora, hay mucho que hacer sobre las prácticas actuales como cosas que surgen cada día de que, tal y como lo vemos, es una ola continua de retos que nos obliga a todos a evolucionar y ser mejores en lo que hacemos.

Estamos orgullosos de dónde estamos, pero ya tenemos la vista puesta en lo que viene. La infraestructura como código, la racionalización aún más de nuestras estrategias de entrega, la automatización de los procesos empresariales y técnicos, la adaptabilidad a los cambios, la independencia de lo que estamos haciendo ahora y el enamoramiento de lo que vamos a hacer después. Estamos muy entusiasmados con nuestros logros con DevOps y a medida que crecemos, mantendremos esta metodología tan cerca de nosotros como sea posible, porque sin ella, el desarrollo de software nunca habría sido lo mismo que es ahora, al menos para nosotros.

¡Únete a nuestro equipo!

¿Te apasiona DevOps? ¡Únete a nosotros! ¡Estamos buscando los mejores talentos para unirse a nuestra familia y empujar aún más nuestro alcance DevOps!