Introducción

Con el pasar de los años el proceso de diseño de software ha ido evolucionando. Un claro ejemplo de ello es el ciclo de vida del desarrollo de software, que ha pasado de ser lineal con el modelo en cascada a iterativo e incremental con las metodologías ágiles. Esto se debe a que los clientes cada vez son más exigentes, tienen expectativas mayores con respecto al contenido de las aplicaciones, exigen aumento en la calidad del software y requieren tiempos de entrega más cortos (^{Brown, 2013}),(^{Kruchten, 2013}). En este contexto, las mipymes de desarrollo de software deben mantenerse a la vanguardia en cuanto a tecnologías, metodologías, tendencias, formas de trabajo, estrategias o cualquier otro factor que les dé un valor agregado con respecto a las otras empresas competidoras del mercado (^{Laukkarinen, Kuusinen, & Mikkonen, 2018}).

Las metodologías ágiles predominan desde el 2002 (^{Ambler & Ambler, 2011}) y los clientes de las empresas desarrolladoras de software requieren una respuesta cada vez más rápida y con mayor estabilidad, segura y predecible. Es decir, una mezcla entre estabilidad y confiabilidad. Es en este punto que nace el movimiento DevOps, el cual fomenta un ambiente de cultura organizacional basado en la colaboración y comunicación entre los equipos de desarrollo (Dev) y operaciones (Ops) en las empresas desarrolladoras de software (^{Dyck, Penners, & Lichter, 2015}), (^{Hussaini, 2014}).

El fin de DevOps es reducir el tiempo que pasa desde que se sube un cambio al repositorio de control de versiones del software que se está construyendo (commit), hasta que el cambio es puesto en producción, garantizando así alta calidad en el software (^{Mohamed, 2015}; ^{Rajkumar, Pole, Adige, & Mahanta, 2016}; ^{Ravichandran, Taylor, & Waterhouse, 2016}). DevOps, como cultura, tiene la característica principal de defender la automatización y el monitoreo en todos los pasos de la construcción del software, desde la integración, las pruebas y la liberación hasta la implementación y la administración de la infraestructura, apuntando así a ciclos de desarrollo más cortos, mayor frecuencia de implementación, lan zamientos más confiables, en estrecha alineación con los objetivos comerciales de la empresa de desarrollo. Al modelo DevOps se le conoce también por el conjunto de actividades del modelo CALMS (por sus siglas en inglés de cultura, automatización, lean, métricas y compartir). El modelo busca cambiar la mentalidad entre los equipos de desarrollo y operaciones para aportar el valor que el negocio espera por parte del área de tecnología. Para ello, busca optimizar y automatizar al máximo las tareas que se ejecutan a lo largo del ciclo de vida de construcción de software, de forma que se pueda implantar en producción lo antes posible con las funcionalidades que el negocio ha solicitado (^{Kort & de Kort, 2016}; ^{Mueller, Wickett, Gaekwad, & Karayanev, 2010}).

Aunque ya ha transcurrido una década desde el nacimiento de DevOps, aún sigue siendo un campo poco explorado en Latinoamérica y los casos de éxito de referencia encontrados pertenecen en su mayoría a grandes empresas de Europa y Estados Unidos. Esto conlleva poca documentación sobre métodos, técnicas, estrategias y lineamientos por seguir para adoptar DevOps en el contexto colombiano, así que la transformación a una cultura DevOps implica un aumento de esfuerzos y costos en las empresas del sector del desarrollo de software.

Basado en lo anterior, este artículo está centrado en proponer unos lineamientos culturales, técnicos y colaborativos que sirvan como guía inicial en la adopción de la cultura DevOps basado en el modelo CALMS enfocado en las mipymes desarrolladoras de software en Colombia, con el fin de que puedan responder a los desafíos cambiantes que exigen los clientes y el mercado internacional del software.

El resto del artículo se encuentra organizado de la siguiente manera. En primer lugar se presenta el contexto de motivación. En el apartado que le sigue, son descritos algunos de los trabajos de mayor relevancia en el campo. La sección siguiente presenta los lineamientos planteados para cada uno de los componentes del modelo DevOps.

Seguidamente, se describe el estudio de caso que se hizo para dar validación a los lineamientos propuestos y finalmente se presentan las conclusiones y el trabajo futuro.

Escenario de motivación

DevOps es un término relativamente nuevo que apareció por primera vez en 2009. Sin embargo, muchos delos conceptos y prácticas que propone existían desde antes. Si bien no hay documentada una especificación clara oestándar de las prácticas de DevOps, el paradigma se ha notado como una de las tendencias tecnológicas en alzaen los últimos diez años (^{Nicolau de França, Jerónimo, & Travassos, 2016}; ^{Riungu-Kalliosaari, Mäkinen, Lwakatare, Tiihonen, & Männistö, 2016}).

El informe de State of DevOps del 2018 (^{Velásquez, Kim, Kersten, & Humble, 2018}), muestra que el 50 % de las empresas encuestadas han adoptado DevOps y están buscando mejoras y el 32 % de ellas planea adoptar DevOps en los próximos doce meses. En el mismo informe también se aclara que se obtienen muchos beneficios al adoptar DevOps en una organización, entre estos está que las organizaciones pueden reducir sus costos de desarrollo y mantenimiento en un 18 %. Además en el informe se reporta que DevOps es la razón principal detrás de los aumentos en los ingresos y la cantidad de nuevos clientes, lo cual se traduce en un aumento del 20 % en los negocios. A la luz de estas cifras, se puede ver claramente que existe un valor real y una oportunidad de mejora de las empresas si adoptan la cultura DevOps, hasta el punto de que empresas como Etsy, Facebook, Amazon y Netflix son líderes en el campo de DevOps. Hoy en día, todo tipo de negocio ha entrado en la acción de DevOps. Así, la compañía de medios Sony Pictures, la compañía de servicios financieros Barclays Bank y el fabricante de productos de construcción USG, son otros referentes del éxito de DevOps.

A pesar de todos estos casos de éxito, el informe de Gene Kim, experto en DevOps, aclara que DevOps es tanto para grandes empresas como Google, Amazon, Facebook y Netflix como también para cualquier organización tecnológica en las que se destaquen las siguientes prácticas:

Con base en las anteriores prácticas, es notable la necesidad de implantar un entorno DevOps en las mipymes colombianas. En este sentido, el presente trabajo expone una serie de lineamientos para la adopción de este modelo de cultura de trabajo, el cual permite mayor flexibilidad y claridad en el momento de iniciar con el proceso de implementación. Busca como efecto de su implementación, el incremento en la productividad, el reconocimiento, ingresos y la visibilidad en el mercado.

Trabajos relacionados

Adoptar e implementar cambios en los procedimientos tradicionales en las empresas siempre resulta complejo y suele requerir una inversión. De esta forma, cada vez que una organización adopta una tecnología, metodología o enfoque nuevo, dicha adopción debe ser impulsada por una necesidad empresarial. En las empresas desarrolladoras de software la adopción de DevOps es una necesidad empresarial que busca incrementar la competitividad de la organización. Con base en esto, los trabajos presentados a continuación plantean las prácticas fundamentales en la implementación de DevOps en las empresas.

En ^{Wettinger, Breitenbücher, Kopp, & Leymann, (2016}), se define a DevOps como un paradigma emer gente que tiene como objetivo integrar estrechamente los desarrolladores con el personal de operaciones, para lo cual enfatiza en que es una ventaja competitiva crítica responder rápidamente a los cambios culturales y organizativos e impulsar constantemente nuevos enfoques, herramientas y artefactos de código abierto para implementar aplicaciones en la nube mediante un proceso automatizado. Para ello, presenta una clasificación sistemática de artefactos DevOps para transformar diferentes tipos de artefactos hacia Tosca (acrónimo del ingles Topology and Orches tration Specification for Cloud Applications), un estándar emergente que propone determinados mecanismos para permitir la portabilidad entre diferentes nubes. El marco se implementa mediante una cadena de herramientas de código abierto de extremo a extremo. Además, valida el enfoque presentado para mostrar su viabilidad práctica medianteun estudio de caso.

Por otra parte, ^{Luz, Pinto, & Bonifácio (2019}), señalan que debido a su creciente interés y definiciones, se sabe poco sobre la comprensión de los profesionales sobre los caminos exitosos para la adopción DevOps (^{Zhu, Bass, & Champlin-Scharff, 2016}). Por lo tanto, se detallan escenarios reales de adopción de DevOps presentando una teoría, un modelo y un estudio de caso. Utiliza quince escenarios de adopción exitosa de DevOps en empresas de diferentes dominios y países. Presenta un modelo (es decir, un flujo de trabajo para la adopción de DevOps) evaluado mediante un estudio de caso en una institución del Gobierno brasileño, y utilización de un grupo de enfoque para recopilar las percepciones de la compañía sobre la adopción de DevOps. Del caso de estudio se detallan escenarios reales y explica el rol de cada categoría durante la adopción de DevOps. A través de esto proporciona evidencia de que la colaboración es el factor la principal en DevOps, en contraste con la automatización, y las herramientas pueden ser suficientes para lograr DevOps.

En ^{Lwakatare et al., (2019}), define a DevOps como importante en la capacidad de actualizar de manera frecuente y confiable un sistema en estado operativo, para lo cual se basa en colaboración y automatización multifuncional entre el desarrollo de software y las operaciones, enfocados en los cambios requeridos en los aspectos técnicos, organizativos y culturales. El trabajo se base en el estudio exploratorio de cómo se implementa DevOps en la práctica en el desarrollo de aplicaciones y servicios web en pequeñas y medianas empresas. Se hizo un estudio de casos múltiples en cinco contextos de desarrollo diferentes con implementaciones de DevOps, ya que se lograron sus beneficios, como lanzamientos rá pidos y errores mínimos de implementación. Los datos se recopilaron principalmente a través de entrevistas con 26 profesionales y observaciones realizadas en las empresas.

A partir del estudio de los trabajos relacionados, se puede identificar que la mayoría de trabajos están centrados en las herramientas, en la integración de la colaboración, en las prácticas de desarrollo y de despliegue continuo. Aunque las prácticas y herramientas son importantes en el entorno DevOps, ninguno de los trabajos se interesa por definir los lineamientos que se deben seguir antes de implementar DevOps en una empresa, ya que estos permiten identificar el estado actual de las prácticas y cuáles serían las de mayor facilidad de implementación en relación al contexto de la empresa.

Lineamientos propuestos

Según Gary Gruver, DevOps debe centrarse en principios de propiedad y flexibilidad en lugar de seguir una hoja de ruta rígida propuesta por un modelo de madurez (^{Sharma, 2017}; ^{The, Of, In, & Software, 2014}). Por lo tanto, los lineamientos propuestos se basan en CALMS que más que un modelo de referencia es una guía de los principios que se deben tener en cuenta en cualquier adopción de DevOps.

El entorno al que se pretende llegar con los lineamientos propuestos es una cultura de DevOps basada en la automatización de inicio a fin; es decir, desde que se sube el cambio del código al repositorio de versiones hasta que es desplegado en el ambiente de producción, mientras se crea una colaboración y comunicación efectiva entre las partes involucradas en la construcción del producto de software.

Como primera medida es recomendable realizar la encuesta de evaluación inicial propuesta,⁴ para así conocer:

Una vez claros dichos puntos, se definen los linea mientos que se deben tener en cuenta en cada uno de los principios de CALMS (Figura 1).

Figura 1 Lineamientos propuestos bajo principios CALMS 

Lineamientos culturales.

En esencia, el éxito de DevOps depende en gran medida de la colaboración entre los desarrolladores y el personal de operaciones de TI. Solo a través del intercambio diario y abierto de conocimiento y mejores prácticas, una empresa puede resolver problemas y optimizar aplicaciones de manera eficiente en DevOps. Reunir puntos de vista cuando es necesario, no solo requiere las herramientas adecuadas, sino también la cultura correcta para fomentar dicha cultura. En este sentido, se propone una serie de actividades/juegos para la construcción de una cultura DevOps.

Objetivos, recompensas y valores compartidos. La colaboración entre operaciones y desarrollo es difícil no porque ninguna de las dos áreas quiera colaborar, sino porque el enfoque es diferente. Desarrollo desea entregar requerimientos nuevos lo más rápido posible, mientras que operaciones tiene como principal medida de éxito la estabilidad. Entonces, ¿cómo lograr que dos grupos de dos mundos diferentes colaboren? Establezca objetivos compartidos, recompensas compartidas y valores compar tidos. Al conectar ambas áreas con un conjunto simple de objetivos (lo que estamos tratando de hacer), recompensas -obtienes esto por hacerlo-gamificación (Navia, 2019)- y valores (esto es lo que espero de todos) se construye un entorno que fomenta y apoya la colaboración.

Pautas de rendimiento. El rendimiento de la aplicación (velocidad y disponibilidad) ha sido la principal fuente de fricción entre el personal de operaciones y el de desarrollo, ya que cuando el rendimiento falla los equipos suelen culparse unos a otros, por lo que se recomienda establecer un conjunto claro de pautas de rendimiento. Por ejemplo, si un producto de software no funciona a un cierto umbral, no entra en producción y todas las versiones futuras quedarán en espera indefinidamente hasta que el primer producto sea corregido.

Empezar poco a poco. A menudo, las empresas que desean cambiarse a un modelo de DevOps intentan hacer el cambio de manera general. Pero normalmente es mejor comenzar de a poco y utilizar un proceso que permita colaborar a todo el equipo. Es decir, en lugar de tratar de automatizar una compilación complicada existente que aporta mucho al negocio y es difícil de administrar por todo el equipo, es mejor comenzar con una compilación simple y trivial para establecer un nuevo proceso limpio de integración y despliegue continuo que todo el equipo pueda entender.

Elija las personas correctas y construya confianza entre los equipos. Seleccione equipos pequeños de trabajo (no más de diez personas) que se caractericen por ser buenos para el trabajo en equipo, dispuestos y capaces de aceptar cambios y nuevas maneras de trabajar. Una vez esté seguro del equipo elegido para la adopción de DevOps, fomente la confianza, la comprensión y la importancia en el trabajo de los demás, incluidos los miembros del perso nal de un equipo en el otro. En conclusión, DevOps no es el trabajo de un equipo sino el trabajo de todos, pues la cultura de DevOps tiene que ver con responsabilidad compartida (^{Grass Ramírez, Collazos Ordóñez, & González González, 2017}; ^{Ramírez, 1939}). Eso significa un cambio hacia la transparencia, la comunicación y la colaboración entre el desarrollo, las operaciones de TI y el negocio.

Lineamientos de automatización

Uno de los principios básicos de DevOps es implementar la automatización en todas las etapas de entrega, desde la verificación del código hasta la implementación, que incluye: integración de código, compilaciones, pruebas, implementación y verificación de las compilaciones implementadas. Esta automatización acelera todas las etapas de la entrega de software para que los desarrolladores obtengan retroalimentación e impacto en sus cambios rápidamente, lo que ayuda a acelerar el tiempo total de comercialización. DevOps depende en gran medida de la automatización y eso significa que necesita herramientas. Estas herramientas no deben estar dispersas en la organización, sino ser una cadena de herramientas compatibles que permitan automatizar gran parte del desarrollo de software de extremo a extremo y el proceso de despliegue (^{Jabbari, Ali, Petersen, & Tanveer, 2016}).

Por las razones anteriores, se hizo un análisis comparativo de las distintas herramientas de cada una de las fases presentes en el ciclo de vida de DevOps, teniendo siempre en cuenta que la propuesta está enfocada en mipymes desarrolladoras de software, las cuales posiblemente no disponen de muchos recursos económicos para la compra de herramientas licenciadas muy costosas

Cadena de herramientas propuesta

Integración continúa. La clave de la integración continua es tener una compilación sin errores con las mejores técnicas y estándares de desarrollo y control de versiones para la posterior puesta en producción del código fuente en los entornos específicos. Herramientas seleccionadas: Jenkins + Git + Maven + SonarQube.

Pruebas de código continuo. El objetivo de las pruebas continuas es proporcionar una respuesta rápida y continua sobre el nivel de riesgo empresarial, en la última compilación que se utiliza para determinar si el software está listo para avanzar a través del proceso de entrega en un momento dado. Herramientas seleccionadas: JUnit + RobotFramework.

Orquestación continua y despliegue. Los contenedores se crean para una implementación rápida y confiable de los componentes de la aplicación en cualquier infraestructura subyacente. Herramienta seleccionada: Docker+ AWS EC2.

Monitoreo continuo. La monitorización continua permite recopilar y analizar datos en entornos de prueba y producción. Herramientas como Librato, Nagios y Logstash generan los datos para el equipo que muestran si el rendimiento ha mejorado o empeorado y ayuda a tomar medidas correctivas para mejorar el rendimiento. Herramienta seleccionada: Prometheus.

Colaboración y comunicación continua. Trabajar por medio de incidentes y cultivar una cultura DevOps requiere comunicación constante y colaboración en equipo. Esto se hace mucho más fácil con la implementación de herramientas de ChatOps, que permiten a las personas comunicarse por correo electrónico, chat, texto, video y teléfono. Un entorno verdaderamente colaborativo brinda acceso a conversaciones y datos en todos los dispositivos, de múltiples formas integradas. Herramienta seleccionada: Slack.

Lineamientos lean

Automatizar todo puede ser un problema que complica en exceso la adopción completa de DevOps. Por lo tanto, es necesario concentrarse en mantener todo lo mínimo, pero útil. Lo que se recomienda es seguir con los siguientes principios de lean:

Lineamientos de métricas y monitoreo

Los lanzamientos frecuentes proporcionan una gran flexibilidad, pero pueden poner en peligro el entorno de producción. Por ello, una aplicación desarrollada debe estar equipada con métricas útiles y ser monitoreada en tiempo real.

Estos son solo algunos ejemplos de lo que puede medir dentro de su entorno DevOps (^{Forsgren & Kersten, 2018}; ^{HERING, DeGrandis, & Forsgren, 2015}):

Lineamientos de compartir/ colaboración / comunicación

Compartir es esencial para mejorar el flujo de comunicación y hacer que las personas trabajen juntas. Por lo tanto, es importante compartir ideas, experiencias y pensamientos dentro del equipo, entre equipos e incluso fuera de la empresa.

Mejorar la comunicación. Las empresas deben mejorar el compromiso general con el equipo de desarrolladores compartiendo lo que ambas partes (desarrolladores y operadores) hacen exactamente. Planee un seminario interno para explicar los procesos y las mejores prácticas que cada uno requiere y aprenda cómo integrar los dos. Desarrolle actividades de creación de equipos que incluyan a todos y emplee un sistema de recompensa para la colaboración en equipo, con gamificación, por ejemplo. Haga que valga la pena que ambos equipos aprendan a trabajar juntos. La educación conjunta tanto del desarrollo como de las operaciones es clave.

Dejar que emerja la ruta deseada. Cada organización se comunica de manera diferente, razón por la cual cuando implemente medidas para alentar la colaboración, establezca una red amplia y luego deje que surja la ruta deseada. No obligue a los equipos a participar en rituales y ceremonias no deseados. Por ejemplo, si las personas dejan de aparecer en las reuniones y comienzan a comunicarse a través de un canal de Slack o páginas wiki en su lugar, ajuste el proceso en consecuencia.

Crear espacio. Debe crear espacio para que los desarrolladores y los equipos de operaciones trabajen. Eso significa compartir espacio físico y emocional si es posible (dejar de interactuar mediante tickets y conocerse como seres humanos).

Herramientas de comunicación. Chat y video. No se trata de centrarse en las herramientas, pero sí contar con herramientas que hagan más fluida y fácil la comunicación y colaboración. Por lo general, esto consiste en un sistema de chat basado en texto.

Comunicación continua. La comunicación continua es clave. Los mensajes de correo electrónico semanales de “qué está sucediendo en producción” (qué se está implementando, nueva infraestructura, etc.), canales de mensajes instantáneos, sesiones de planificación semanal y herramientas comunes de emisión de boletos, mantienen a todos sincronizados.

Caso de estudio

Nombre de la empresa: en adelante EMP

Tamaño de la empresa: 18 personas distribuidas así:

Desarrollo: 12 personas.

Operaciones: 3 personas.

Administrativo: 3 personas.

Producto a automatizar

La automatización de inicio a fin se trabajó sobre uno de los productos de software propios de la empresa llamado EMPTeam, en el cual el personal debe registrar las horas y actividades trabajadas durante el día.

Estado actual DevOps-cultura. Personal de desarrollo y de operaciones abiertos al cambio, a aprender nuevas tecnologías, a iniciar cambios culturales y lo más importante de todo, conscientes de la necesidad de empezar a adoptar DevOps como parte de la transformación tecnológica del mercado y de la empresa.

Estado actual DevOps-automatización. No hay proceso automático de compilación, pruebas unitarias y funcionales, revisión de código estático y despliegue; es decir, todo el proceso de puesta en producción se hace manualmente.

El diagnóstico del estado actual en cuanto a los dos pilares centrales de DevOps (cultura y automatización) surge como resultado de la encuesta.⁵ Por esta razón, el caso estudio se centrará en atacar el pilar mas débil de EMP (Figura 2); es decir, la automatización en todo el ciclo de construcción del software.

Figura 2 EMP frente a competidoras 

Para esto se plantea un pipeline de CI/CD al que se espera llegar con los lineamientos de automatización propuestos (Figura 3).

Figura 3 Diagrama de CI/CD propuesto 

Paso a paso del CI/CD propuesto

Descripción del Paso a Paso

• El commit/pull request dispara el inicio del proceso de CI/CD.

• Se compila el código fuente.

• Se ejecutan las pruebas unitarias.

• Se realiza el análisis de código estático.

• Se despliega el artefacto generado en el ambiente de Desarrollo.

• Una vez se ejecutan y pasan las pruebas funcionales automatizadas despliega el artefacto en el ambiente de Pruebas.

• Una vez se ejecutan y pasan las pruebas funcionales automatizadas se ejecutan las pruebas de seguridad y rendimiento.

• Se realiza el despliegue del artefacto generado en el ambiente de producción.

• Una vez el despliegue pase las pruebas de humo, se guarda un backup como versión estable de producción.

• Se verifica la existencia de inestabilidades operacionales post implementación.

• Si se encuentran inestabilidades, se hace un despliegue manual de una versión estable.

• Si no se encuentran inestabilidades, el proceso finaliza.

Nota: si cualquier paso del pipeline propuesto falla, se notifica al equipo de desarrollo y el pipeline no avanza al siguiente paso.

Sin embargo, para llegar hasta este nivel de automatización es necesario hacer un recorrido previo en el que gradualmente se vayan incrementando las actividades por hacer y las tecnologías por utilizar en el pipeline de CI/CD, ya que como se sugirió en el lineamiento de “empezar poco a poco” la adopción de DevOps debe ser gradual, iterativa e incremental por lo que para el caso estudio propuesto no habrá una complejidad inicial tan alta y se enfocará principalmente en una configuración estándar de CI con Jenkins, compilación y ejecución de pruebas unitarias con Maven, revisión de código estático con SonarQube y despliegue por comandos Shell en un servidor controlado (Figura 4) para así obtener una victoria rápida e ir creciendo exponencialmente hasta lograr la madurez esperada.

Figura 4 Pipeline de CI/CD - Caso Estudio 

Resultados del caso de estudio

Con el pipeline de CI y despliegue Shell trabajado en el caso estudio, se obtuvieron resultados exitosos durante el primer mes de uso en cuanto a las dos métricas principales por evaluar, de la siguiente manera:

Frecuencia de despliegues. Se pasó de hacer un despliegue semanal a un despliegue diario, incrementando así en 5x la cantidad, como se observa en la Figura 5a.

Figura 5a Frecuencia de Despliegues mensuales No DevOps Vs DevOps. 

Tasa de éxito de implementación. Se pasó de un porcentaje del 75 % de despliegues exitosos al mes (uno de cada cuatro fallaba) a un 80 %. Es decir, que de los 20 despliegues que se hicieron 16 fueron puestos exitosamente en producción (Figura 5b)

Figura 5b Tasa de despliegues exitoso 

Estos resultados se vieron reflejados en una alta satisfacción del cliente, quienen informaban de manera informal que ya no percibían cuando se desplegaban cambios nuevos y finalmente creció la confianza y la felicidad del personal de desarrollo y de operaciones con las prácticas y tecnologías implementadas, pues veían cómo los frutos de sus desarrollos ya no eran retenidos y no se perdía tiempo en tareas manuales, tiempo que empezó a ser invertido en estudio y capacitaciones en hora laboral enriqueciendo así el salario emocional de todos en la empresa.

Conclusiones y trabajo futuro

De acuerdo con el concepto de adopción de DevOps y la información relevante resumida durante la revisión de la literatura, se identificaron los puntos principales que sirven como pilares en todo proceso de adopción de DevOps. Estos pilares y encuestas determinaron la necesidad, la motivación y el estado actual y nivel de madurez de DevOps.

Los lineamientos propuestos e dividen principalmente en dos grandes grupos: lineamientos culturales (actividades, reuniones, equipos de trabajo, motivaciones, salario emocional, etc.) y lineamientos técnicos (integración continua, compilaciones automatizadas, pruebas automatizadas, revisión de código estático y entrega/despliegue continuos).

La validación del método de adopción de DevOps fue realizada con la ayuda del equipo de TI de la empresa, la cual demostró que con tan solo una pequeña implementación técnica de CI/CD los resultados fueron notorios y se evidenciaron principalmente en el ahorro en tiempo invertido en hacer tareas repetitivas de forma manual.

Después de elegir el objeto de adopción de DevOps y establecer métricas relevantes, la empresa puede continuar con el proceso de adopción de DevOps completo, con la ayuda de los lineamientos de DevOps propuestos y la lista de herramientas de soporte seleccionadas.

Como trabajo futuro se pretende la aplicación de los lineamientos en más empresas, implementación de una cadena de herramientas más robusta y madura y finalmente, la generación sistémica de documentación para asegurar que todos los componentes de la propuesta estén continuamente actualizados y sean consistentes.