Implementación de Entrega Continua en los Sistemas ... · universidad técnica federico santa...

universidad técnica federico santa maría

departamento de informática

magíster en tecnologías de la información –––

1

Implementación de Entrega Continua en los Sistemas Informáticos de una Institución Pública

Rodrigo Cortez Casanova

El Roble 1251, Huechuraba, Santiago.

[email protected]

Resumen: El trabajo que se presenta a continuación consta en mejorar los procesos de instalación de componentes en los ambientes pre productivos y productivos que actualmente existen en la Unidad Tecnológica de una Institución Pública. Es en esta institución existen numerosas aplicaciones en distintas tecnologías y/o lenguajes que no se encuentran estandarizados y que tienen distintos carriles de instalación, además lo realizan diferentes personas de acuerdo a un conocimiento específico. Lo anterior produce atrasos en puestas en producción, riesgos en las aplicaciones y un alto costo humano al no tener procesos automáticos que puedan ayudar a compilar y realizar las pruebas unitarias. Por lo anterior se propone utilizar Lean Thinking para la optimización de los procesos y el enfoque de ingeniería Entrega Continua que trata en crear pipeline o carriles de instalación desde los ambientes de desarrollo hasta los ambientes productivos por cada aplicación, en el cual se definen escenarios y trabajos para realizar procesos automáticos, informando al desarrollador si es el componente se encuentra correcto o tiene errores mientras avanza en cada uno de los carriles. La implementación de Entrega Continua mejoró en más de un 70% los tiempos de entrega la corrección de errores de aplicaciones y mejoras de componentes. Para validar la metodología se utilizó el KPI de velocidad de despliegue con el antes y el después de la solución propuesta.

1. Introducción

Actualmente en la Institución Pública existen numerosos sistemas informáticos para manejar su negocio y controlar los procesos internos. Estos sistemas son administrados por la Unidad Tecnológica, algunos de ellos nacieron cerca de los años 90 y se han mantenido durante el tiempo, además el número de sistemas han ido creciendo a medida que las subdirecciones y regionales han enviado nuevos requerimientos. Solo algunos de estos sistemas han sido migrados a nuevas tecnologías, debido a los altos costos de migrar sistemas complejos, por la necesidad de desarrollar nuevos sistemas y por realizar mantenciones y/o mejoras en los sistemas actuales, recordar que los recursos son finitos. Cabe mencionar que cada cierto tiempo se definen nuevas arquitecturas por el avance tecnológico, por lo tanto, los sistemas migrados, nuevamente irán quedando como legacy.

1.1. Problemas Detectados

El efecto anteriormente mencionado produce que la Unidad Tecnológica tenga una cantidad no menor de sistemas que tiene mantener en distintas tecnologías, las principales son Cobol, CGI, C, Java, ASP, ASP.NET y VB. Cada componente de mejora o corrección en los sistemas pasa por ambientes de estabilización, certificación y luego producción y todos de diferentes formas de acuerdo a la tecnología en que fue desarrollado el sistema.

El tiempo de instalación de componente desde que se encuentra desarrollado hasta la puesta de producción puede tomar días debido a los procesos actualmente definidos (documentación, permisos, tiempo de las personas, etc.), este tiempo también depende según la tecnología en que fue desarrollado el sistema. Por ejemplo, un caso actual es que las personas que trabajan en el área de Middleware son los que reciben los artefactos compilados por los desarrolladores y son los encargados de administrar los pasos a certificación de los componentes Java, al contrario de la instalación de componentes CGI y ASP, en el cual se preocupan los mismos programadores de instalar los componentes en certificación de forma manual. La instalación en

Universidad Técnica Federico Santa María

Departamento de Informática

Programa de Magíster en Tecnologías de la Información

2

producción los realiza la Oficina de Instalación Productiva (OIP) y son asignados a personas específicas que saben cómo realizar la instalación del componente (dependiendo del lenguaje) y además existen distintos procesos y documentación que hay que entregar dependiendo de la tecnología en que fue desarrollado el sistema.

Lo anterior forma cuellos de botella importantes que demoran las entregas de las mejoras, correcciones y/o necesidades requeridas por las subdirecciones y/o regionales en los sistemas informáticos al no tener un único carril de instalación. La motivación nace por redefinir los procesos, estandarizar y principalmente automatizar la instalación de componentes, mediante una vía, sin depender de la tecnología o lenguaje del componente, utilizando un enfoque de ingeniería de software en que la instalación de componentes en todos sus ambientes se produzca en ciclos cortos, de la forma más simple posible, evitando riesgos y realizando testing automáticos.

1.2. Propuesta de Solución

Para solucionar los problemas mencionados en el punto anterior se debe establecer un enfoque de software transversal que implique a las Áreas de Desarrollo, Middleware y Producción de la Unidad Tecnológica de la Institución Pública, y a su vez redefinir los procesos para que la instalación de componentes tenga la mínima intervención de personas, se administre sobre una misma plataforma, que maneje diferentes carriles de instalación según la tecnología y lo más automatizado posible pero con un toque humano.

Los componentes de TI involucrados dentro de este enfoque contemplan la instalación de componentes en los ambientes pre productivos, además de generar testing automático con envío de resultados de instalación a las personas involucradas.

1.3. Objetivos Específicos

De acuerdo a la problemática mencionada en los puntos anteriores existen los siguientes objetivos específicos que se pretende solucionar con los enfoques mencionados:

a) Reducir significativamente los tiempos en puesta de producción de las versiones de componentes y la detección temprana de errores durante las instalaciones de componentes en los ambientes pre productivos.

b) Centralizar la instalación de componentes de los aplicativos más relevantes sobre una plataforma única sin importar la tecnología en que fue construida la aplicación.

Es importante tener estos objetivos alineados al momento de definir los procesos de instalación de componentes en los ambientes. Estos objetivos otorgarán un rápido, fácil acceso para la instalación de componentes en los ambientes pre productivos, además de generar reportes de errores mediante herramientas automática de testing hacia los desarrolladores. Por último, la centralización de las instalaciones y al utilizar una plataforma única ayudará a ordenar los componentes y prescindir de la experiencia de personas expertas de una tecnología o plataforma para la instalación de componentes.

1.4. Hipótesis

De acuerdo a lo mencionado anteriormente, eliminando y optimizando las etapas o procesos de instalación de componentes que no generen valor usando la metodología de Lean Thinking e implementado Entrega Continua en los proyectos de la Unidad Tecnológica de la Institución Pública, se mejorará en más de un 70% los tiempos la instalación de componentes en los ambientes pre productivos y productivos para incorporar mejoras y/o solucionar errores solicitados por las subdirecciones y regionales en los sistemas informáticos al tener la automatización y control de pruebas en el despliegue de componentes.

La solución pasa por crear pipelines de desarrollo de software por cada sistema informático. Estos pipelines empiezan desde que el componente es subido al software de control de versiones al término de la fase de desarrollo, luego se utiliza el servidor de integración (Integración Continua) que chequea y compila el código, y por último, el software de automatización (Entrega Continua) que lleva a cabo los despliegues a las distintas plataformas. La implementación de los pipelines se realizará sobre tres arquitecturas, en los sistemas construidos en lenguaje ASP, Java y C.




3

1.5. Metodología de Validación

Actualmente la Unidad Tecnológica se encuentra utilizando el software Jira para el reporte de incidencias, mejoras a los sistemas, labores operativas, instalaciones en ambientes pre productivos y productivos, por lo tanto, es posible medir cuantitativamente desde que se levanta un requerimiento de instalación hasta la puesta en producción y comparar los resultados con el proyecto planteado.

Los indicadores clave de rendimiento, también conocidos como KPI o Indicadores de Éxito Clave, ayudarán a medir la efectividad de varias funciones y procesos importantes para alcanzar los objetivos definidos. Cuando se definen KPIs se suele aplicar el acrónimo SMART [1], ya que los KPIs tienen que ser:

● Específicos (Specific) ● Medibles (Measurable) ● Alcanzables (Achievable) ● Relevantes (Relevant) ● Temporales (Timely), en el sentido de que sea posible hacer un seguimiento de su evolución en el tiempo.

EL KPI a utilizar para efectos de la hipótesis son:

La velocidad de despliegue: tiempo en que tarda una única implementación de una aplicación, expresado como el número de días a partir de la historia abierta a la ejecución de la producción.

Los siguientes KPI darán a conocer la calidad de los componentes que son instalados en los ambientes pre productivos una vez que se implemente la Entrega Continua mediante.

Frecuencia de despliegue: frecuencia en que se libera una nueva versión de una aplicación, medido por el número de despliegues al mes, semana, día u hora.

Tasa de éxito de éxito de despliegue: El porcentaje de los despliegues en producción que se consideran como éxito.

Tasa de éxito-implementación sin producción: El porcentaje de los despliegues en producción que se consideran con éxito después de la validación.

Incidentes y defectos: El número de incidentes y la notificación de defectos en una versión específica de una aplicación.

2. Marco conceptual

El propósito de la investigación corresponde a facilitar y mejorar los tiempos de instalación de componentes en los ambientes pre productivos de los sistemas que actualmente administra la Unidad Tecnológica. Por lo anterior se enfocará en dos conceptos o enfoques claves: “Lean Thinking” para eliminar los procesos o actividades que no generen valor en el despliegue de componentes y “Entrega Continua” o Entrega Continua para la automatización de la instalación y despliegue de componentes. Lo anterior se encuentra muy relacionado con DevOps (desarrollo y operación) que consiste en buenas prácticas para automatizar los procesos entre los equipos de desarrollo de software y TI para que puedan compilar, probar y publicar software con mayor rapidez y fiabilidad.

2.1. Lean Thinking

Lean thinking como su nombre lo indica, es en realidad una mentalidad, una perspectiva de visualizar el mundo. Lean se trata de centrarse, eliminar los procesos que no generan valor y aumentar el valor al usuario. Lean se trata de realizar un proceso fluido, haciendo sólo aquellas actividades que agregan valor al usuario y eliminando todas las demás actividades que no lo hacen [3].




4

Esta metodología de negocio enseña sobre el “valor” y en “reducir las pérdidas”, esto quiere decir que cualquier paso dentro del proceso de instalación de componentes ya sea doble digitación, documentación innecesaria, paso o proceso que no agregue algún valor debe ser considerado como un desperdicio [2]. Y como segundo concepto fundamental que se tomará del Lean Thinking es la automatización de procesos, pero no por sí sola, sino que con un “toque humano”, y el concepto “built-in quality” que se refiere al uso herramientas y ayudas visuales de seguimiento riguroso de la calidad durante el proceso de paso a producción [4]. Los procesos más críticos de instalación de componentes tienen que ser supervisados por personas sobre todo en las etapas productivas. Si bien la automatización mejora los tiempos puede traer problemas si no se tiene un completo control. Por lo anterior es importante disponer de herramientas que proporcionen información de lo que está ocurriendo.

2.1.1. Etapas Lean Thinking

Para llevar a cabo esta metodología de negocio se debe tener en cuenta las siguientes etapas con respecto a un componente [10]:

Tabla 1. Fuente: https://www.labce.com/spg539540_five_steps_to_lean_thinking.aspx

ETAPA DESCRIPCIÓN

Especificar valor El punto de partida crítico. Definir el valor desde la perspectiva del usuario y expresar el valor en términos de un componente específico.

Asignar un mapa de la cadena de valor

Mostrar todos los pasos que ha pasado un componente al usuario. Incluye: Valor agregado: Actividades que son de valor para el usuario. Valor que habilita: No valorado por el usuario, pero requerido para el proceso. Valor no agregado: no crean valor y son evitables.

Establecer el flujo Establecer el continuo movimiento del componente, servicios e información desde el principio hasta el final.

Definir el “Pull” Definir cuando un componente entra al flujo

Perseguir la perfección La perfección es la eliminación de todos los residuos, para que todas las actividades del proceso creen valor para el usuario (mejoramiento continuo)

Lean Thinking se centra en el flujo de procesos y cualquier actividad que no agregue valor lo califica como desperdicio. Esta metodología utiliza los siguientes diagramas: mapeo de procesos, diagrama de flujo y mapeo de flujos de valores, para entender el flujo completo del proceso.

2.1.2. Sistemas 5S

Una herramienta importante usada en el Lean thinking es el sistema de organización 5S.

5S es un sistema para reducir el desperdicio, optimizar la productividad a través del uso de herramientas para mantener el orden de los procesos y hacer uso de indicadores visuales para lograr resultados operativos más consistentes. La implementación de este método consiste en “limpiar” y organizar los flujos de la configuración que existe actualmente. [9]




5

Los pilares 5S son, Sort (Seiri), Set in Order (Seiton), Shine (Seiso), Standardize (Seiketsu) y Sustain (Shitsuke), proporcionan una metodología para organizar, limpiar, desarrollar y sostener el ambiente productivo [11]:

Organizar (Sort): Es el primer S y se centra en la eliminación de elementos innecesarios dentro de los flujos

Poner en Orden (Set in Order): Se centra en la creación de métodos de almacenamiento eficientes y eficaces para la organización de componentes y estos sean fáciles de encontrar. Establecer el orden sólo se puede implementar una vez que el primer pilar Sort ha eliminado los elementos innecesarios.

Brillar (Shrine): Una vez que el desorden es eliminado y los componentes se han organizado, el paso siguiente es “limpiar” a fondo el área de trabajo. La “limpieza” diaria y el seguimiento de este pilar es necesaria para sostener esta mejora.

Estandarizar (Standardize): Una vez que los tres primeros 5S se han puesto en práctica, el siguiente pilar es la estandarización de las mejores prácticas. Estandarizar el método para mantener los primeros tres pilares, crea un enfoque consistente con el que se realizan procedimientos.

Sostener (Sustain): Hacer el hábito de mantener correctamente los procedimientos correctos, es a menudo el 5S más difícil de implementar y lograr.

2.2. Entrega Continua

La Entrega Continua es un enfoque de la ingeniería de software que consiste en desarrollar un proceso transversal que permite liberar nuevas versiones de componentes de software listos para ser instalados en ambientes productivos de forma automatizada, rápida y programada sin importar o el lenguaje o tecnología de desarrollo.

Figura 1. Ciclo de Entrega Continua. Fuente: https://www.appliedis.com/expertise/devops

En otras palabras, la Entrega Continua es un proceso en la cual se crean, prueban y preparan automáticamente los cambios en el código y se entregan para la fase de producción. Amplía la Integración Continua al implementar todos los cambios en el código en un entorno de pruebas y/o de producción después de la fase de creación. Cuando la Entrega Continua se implementa de manera adecuada, los desarrolladores dispondrán siempre de un artefacto listo para su implementación que se ha sometido a un proceso de pruebas estandarizado

Con la Entrega Continua, todos los cambios en el código son testeados, se envían a un entorno de almacenamiento de versiones y se realizan pruebas pre productivas. Es posible efectuar varias pruebas al mismo tiempo antes del despliegue a producción. En el último paso, el área encargada de los ambientes productivos aprueba la actualización para su instalación. La metodología de Despliegue Continuo se diferencia de la Entrega Continua en que el envío a producción se efectúa automáticamente, sin una aprobación explícita.




6

Este enfoque permite a los desarrolladores automatizar las pruebas más allá de las pruebas de unidades, por lo que pueden verificar actualizaciones en las aplicaciones en varias dimensiones antes de enviarlas a los clientes. Las pruebas pueden incluir pruebas de la UI, de carga, de integración, de fiabilidad de la API, etc. De este modo, los desarrolladores pueden validar las actualizaciones de forma más exhaustiva y descubrir problemas por anticipado. [5].

Por lo tanto, la Entrega Continua establece [6]:

- Detección temprana de problemas y potenciales errores - Rapidez y simplicidad en puesta en producción de nuevas versiones. - Realizar tareas automatizables. - Conocimientos de los procesos debido a la iteración sobre el mismo.

Entrega continua contempla los conceptos de Integración Continua. La Integración Continua describe la práctica de garantizar que aplicación es utilizable en todas las etapas del proceso de desarrollo. Esto quiere decir que cada vez que un desarrollador realiza un commit en el control de versiones se encontrará integrado al instante en la aplicación y además se realizan pruebas de aceptación para garantizar la solidez y estabilidad del sistema. Entrega continua toma la idea de Integración Continua, pero con un paso más y exige que el componente no sólo esté disponible en los ambientes pre productivos, sino que también se encuentre en un estado de liberación o final. Por lo tanto, Entrega Continua es la práctica de la implementación de cada versión de la aplicación que ha superado las pruebas necesarias y se encuentra listo para instalación en producción [7].

Otro concepto dentro de este marco es el Despliegue Continuo que va un paso más allá de la Entrega Continua. Con esta práctica, cada cambio que pasa todas las etapas del pipeline llega a producción. No hay intervención humana, y sólo una prueba fallida impide que un nuevo cambio se despliegue hasta la etapa final del pipeline.

El Despliegue Continuo es una excelente manera de acelerar el ciclo de retroalimentación y de quitarle presión los equipos de cada una de las áreas (desarrolladores, middleware, producción) ya que el cambio o mejora se puede visualizar en los ambientes productivos casi inmediatamente. Los desarrolladores pueden centrarse en la construcción de software, y ver su trabajo en minutos después de haber terminado de trabajar en él.

Figura 2. Pipeline Despliegue Continuo. Fuente: https://devops.com/i-want-to-do-continuous-deployment/

Ahora, debido a que los sistemas de la Institución Pública son críticos y con una alta carga debido a las consultas o trámites de las personas naturales, el Despliegue Continuo no será implementado por la Unidad Tecnológica. No obstante, para los sistemas internos y que solo son usados por los funcionarios internos existe la oportunidad de implementar esta práctica, pero será evaluado con posterioridad una vez que se vean los resultados de la Integración Continua y Entrega Continua.

2.2.1. Beneficios de cada Práctica

Si bien existen numerosos beneficios al implantar esta práctica también existen costos asociados que deben de asumir los equipos y la Unidad Tecnológica para que funcione correctamente. A continuación, se presenta una tabla con los beneficios de cada una de las prácticas que se implementarán en la Unidad Tecnológica.




7

Tabla 2. Fuente: https://es.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd

PRÁCTICA QUÉ SE NECESITA (COSTO) QUÉ SE GANA

Integración continua

El equipo de desarrollo tendrá que escribir pruebas automatizadas para cada nueva función, mejora o corrección de errores.

Es necesario un servidor de Integración Continua que pueda monitorear el repositorio principal y ejecutar las pruebas automáticamente para cada nuevo commit.

Los desarrolladores necesitan combinar sus cambios lo más frecuentemente como sea posible, al menos una vez al día.

Menos cantidad de errores se envían producción debido a que son capturados de forma temprana por las pruebas automatizadas.

La instalación de componentes es fácil ya que todos los problemas de integración se han resuelto de forma temprana.

Menos cambio de contexto, ya que los desarrolladores son alertados de errores cuando se realiza compilación y pueden trabajar en arreglarlo antes de pasar a otra tarea.

Los costos de las pruebas se reducen drásticamente: El servidor de Integración Continua puede ejecutar cientos de pruebas en pocos segundos.

El equipo de control de calidad pasa menos tiempo probando y puede centrarse en mejoras significativas en la cultura de calidad.

Entrega continua

Es necesario una base sólida en la Integración Continua y la suite de pruebas debe cubrir las diferentes tecnologías de programación.

Las implementaciones deben ser automatizadas. La acción de ejecutar el pipeline sigue siendo manual, pero una vez que se ha iniciado un despliegue no debe haber de intervención humana.

Es muy probable que el equipo necesite adoptar indicadores o alertas para que los componentes con errores no afecten a los sistemas productivos

Se elimina la complejidad del despliegue de componentes. El equipo no tiene que pasar días preparándose para una instalación en los ambientes pre productivos.

Las liberaciones son más frecuentes, acelerando la retroalimentación con los clientes.

Existe menos presión sobre las decisiones de instalación de pequeños cambios, por lo tanto, alienta que la iteración de cambios sea más rápida.

Uno de los costos asociados con la Entrega Continua es la instalación y el mantenimiento de los servidores. Es posible reducir significativamente el costo de adoptar estas prácticas mediante softwares que permitan cargar archivos de configuraciones a partir de otros pipelines generados. Esto es importante para facilitar la tarea a los




8

encargados de la Entrega Continua. Más adelante se analizarán algunos de los softwares utilizados en el mercado que permitan este tipo de configuraciones.

Para automatizar el proceso de instalación de las versiones de las aplicaciones en los diferentes entornos se debe implementar diferentes pipelines según la tecnología de aplicación y servidores en que reside, además es necesario desarrollar mecanismos para volver al estado estable en caso de fallo durante la instalación y por último también se debe configurar un mecanismo para informar el estado de las instalaciones de los diferentes entornos para la detección temprana de errores.

2.2.2. Pipeline

En un nivel abstracto, un pipeline de despliegue es una manifestación automatizada de varios procesos automatizados para obtener el componente desde el control de versiones hasta la puesta en ambientes pre productivos (esto es en el caso de Entrega Continua). Cada cambio dentro de un software pasa por un proceso complejo para ser instalado. Este proceso implica la construcción del software, seguido por el progreso de compilaciones a través de múltiples etapas de pruebas y despliegue. Esto en la realidad requiere la colaboración de muchas personas y varios equipos. El pipeline de despliegue modela este proceso en una herramienta de administración continua de integración y liberación la cual permite visualizar y controlar el progreso de cada cambio a medida que pasa desde el control de versiones a través de varios conjuntos de pruebas e implementaciones para luego pasar en un estado listo y ser desplegado en producción [7].

Por lo tanto, el proceso modelado por el despliegue del pipeline, el proceso de obtener el componente desde el check-in hasta la liberación forman parte del proceso de obtener nuevas características en los softwares. Todo el proceso, desde el concepto hasta la liberación, puede ser modelado mediante un mapa de flujo de valor. En la siguiente figura se muestra un ejemplo de un mapa de flujo de valores de alto nivel para el despliegue de componentes.

Figura 3. Mapa Flujo de Valor. Fuente: https://feeney.mba/2016/03/11/using-devops-to-improve-the-value-chain

Como se aprecia en la figura todo el proceso toma alrededor de tres meses y medio y la parte importante es minimizar los tiempos que existen entre las brechas de desarrollo, las pruebas y la liberación final. Según el ejemplo, toma 5 días entre que el equipo de desarrollo termina la construcción del componente y pasa al equipo de calidad, lo anterior puede deberse al tiempo que tarda en desplegar la aplicación en un entorno de tipo pre productivo y además es posible que esto sea un proceso iterativo lo que significa que los tiempos se elevarían considerablemente.

De la figura solo interesa la parte del flujo que encuentra con cuadros sombreados y una diferencia clave es que las compilaciones pasan a través de él muchas veces antes de que sea liberado en producción. Una manera de entender el pipeline de despliegue y cómo los cambios se mueven a través de ella, es visualizándolo dentro de un diagrama de secuencia, como se muestra en la siguiente figura.




9

Figura 4. Diagrama de Secuencia. Fuente: https://www.kn-portal.com/fileadmin/xxx/AgileReleaseManagement-whitePaper.pdf

Se puede observar que la entrada del pipeline es una revisión particular dentro del control de versiones. Cada cambio en el software crea un componente que pasará por una secuencia de pruebas y si es viable pasará a producción. El proceso de secuencia de prueba evalúa la construcción del componente en cada etapa desde una perspectiva diferente y se inicia con cada commit desde el sistema de control de versiones, de la misma forma que el inicio de un proceso de Integración Continua.

A medida que el componente pasa por cada prueba, la confianza aumenta, por lo tanto, los recursos que se están dispuestos a gastar aumentan, lo que significa que los ambientes por los que pasa el componente se vuelven progresivamente más productivos. El objetivo es eliminar del proceso a los candidatos de componentes con errores tan pronto como sea posible y obtener retroalimentación sobre la causa raíz del fracaso al equipo lo más rápido que se pueda. Al final, cualquier compilación que falla en una etapa del proceso no será promovida a la siguiente. Lo anterior se puede visualizar en la siguiente figura:

Figura 5. Pipeline Entrega Contniua. Fuente: "Reliable Software Releases through Build, Test, and Deployment Automation”




10

Existen algunas consecuencias importantes de aplicar este patrón. En primer lugar, efectivamente se está previniendo la instalación en producción de componentes que no se han probado a fondo y que se que son candidatas para solucionar un error. Recordar que para mitigar los errores de regresión se necesitan correcciones urgentes en producción (estas correcciones pasan por el mismo proceso como cualquier otro cambio). Según la experiencia, también es extremadamente común que el software recién construido tenga problemas en producción debido a alguna interacción imprevista entre los componentes del sistema y su ambiente, por ejemplo, debido a una ligera diferencia en la configuración de un servidor de producción o que existan librerías deprecadas. La disciplina pipeline de despliegue permite mitigar estos escenarios.

Cuando los despliegues son automatizados, estos son rápidos, repetibles y confiables. A menudo es mucho más fácil realizar liberaciones una vez que el proceso se automatiza y se conviertan en un evento "normal", lo que significa que es posible realizar releases con más frecuencia. Esto caso particular también sucede cuando se tiene que volver a una versión anterior, son más fáciles de ejecutar. Cuando se tiene la funcionalidad antes mencionada las instalaciones son casi sin riesgo.

Para lograr la Entrega Continua se tiene que automatizar las pruebas de aceptación que demuestran que los componentes candidatos para instalación en producción se encuentran aptos y sin errores. También se debe automatizar la implementación en los ambientes de pruebas, ambientes productivos y estadísticas, se deben eliminar estos pasos manualmente ya que son propensos a errores. Existen diferentes formas de pruebas y etapas dentro del proceso de confección del pipeline, pero un subconjunto común de proyectos es el siguiente:

Tabla 3. Fuente: https://es.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd

ETAPA DESCRIPCIÓN

Commit state Afirma que el sistema funciona a nivel técnico. Compila, pasa un conjunto de pruebas automatizadas (principalmente a nivel de unidad) y ejecuta el análisis de código.

Manual stage state

El sistema es utilizable y cumple con sus requisitos, identifica cualquier defecto que no haya sido detectado por pruebas las automatizadas y verifica que proporcione valor a los usuarios. Estas etapas pueden incluir típicamente entornos de pruebas exploratorias, entornos de integración y UAT (user acceptance testing).

Manual stage state Afirman que el sistema funciona a nivel funcional y no funcional, el comportamiento satisface las especificaciones y necesidades del usuario

Release stage Entrega el sistema a los usuarios, ya sea como software empaquetado o desplegándose en un entorno de producción o de puesta en marcha (un entorno de ensayo es un entorno de prueba idéntico al entorno de producción).

2.3. DevOps

DevOps es un acrónimo inglés de development (desarrollo) y operations (operaciones), que se refiere a una metodología de desarrollo de software que se centra en la comunicación, colaboración e integración entre desarrolladores de software y los profesionales de sistemas en las tecnologías de la información (IT). DevOps es una respuesta a la interdependencia del desarrollo de software y las operaciones IT. Su objetivo es ayudar a una organización a producir productos y servicios software más rápidamente, de mejor calidad y a un coste menor. Además, el concepto de DevOps se basa en establecer una cultura de colaboración entre equipos que,




11

tradicionalmente, trabajaban en grupos aislados. Entre las ventajas que promete, se incluyen el aumento de la confianza y de la velocidad de publicación de software, la capacidad de solucionar incidencias críticas rápidamente y una mejor gestión del trabajo imprevisto [15].

Como esta práctica pretende ser un modo de trabajo interfuncional, en lugar de una sola herramienta DevOps existen conjuntos (o "toolchains") de múltiples herramientas. Se espera que tales herramientas de DevOps encajen en una o más de estas categorías, que reflejen los aspectos clave del proceso de desarrollo y entrega[14]:

Código: Desarrollo y revisión de código, herramientas de administración de código fuente, fusión de código. Construcción: Herramientas de integración continua, estado de compilación. Prueba: Herramientas de prueba continuas que brindan retroalimentación sobre los riesgos comerciales. Paquete: Repositorio de artefactos, distribución previa a la implementación de la aplicación. Lanzamiento - Gestión de cambios, aprobaciones de versiones, automatización de versiones. Configurar - Configuración y gestión de la infraestructura, Infraestructura como código. Monitor : Monitoreo del rendimiento de las aplicaciones, experiencia del usuario final.

Figura 6. Intersección de Desarrollo, Operaciones de Tecnología y Calidad. Fuente: “https://es.wikipedia.org/wiki/DevOps”

2.3.1. Control de Versiones

El control de versiones de software es el proceso de asignar números o nombres de versión únicos a estados únicos de sistemas de software. Dentro de la categoría número de versión (mayor, menor), las versiones se asignan generalmente en orden creciente y corresponden a nuevos desarrollos dentro de un sistema de software. En un nivel más fino, el control de revisión se utiliza a menudo para hacer un seguimiento de las diferentes versiones a medida que se van generando cambios mínimos en las aplicaciones del sistema [8].

3. Optimización de los Procesos de Instalación de Componentes

Las metodologías mencionadas anteriormente serán aplicadas para reducir los tiempos de instalación de componentes en los ambientes pre productos y productivos, pero antes se explicará en detalle las actividades y etapas actuales para ejecutar estas instalaciones en desarrollo, estabilización, certificación y producción de los distintos sistemas que administra la Unidad Tecnológica.




12

3.1. Proceso Actual de Instalación de Componentes (AS-IS)

Actualmente en la Unidad Tecnológica existe una serie de pasos o procedimientos para ciclo de desarrollo de software. En el informe se describirán sólo los procesos relacionados con la instalación de componentes desde que el desarrollador sube los cambios al control de versiones hasta la instalación de producción de acuerdo a la tecnología usada. Cabe mencionar que debido a la diversidad de arquitecturas y lenguajes de programación el deployment de componentes tienen distintos procesos y se realizan de manera diferente. Como se mencionó anteriormente se enfocará solo en los procesos de instalación de los sistemas escritos en Java, ASP y C. Para la instalación en producción es el mismo proceso para todas las tecnologías por lo que se describirá en forma separada.

3.1.1. Java

La Unidad Tecnológica mediante un gran esfuerzo ha tratado de establecer una arquitectura modelo con las últimas tecnologías en el mercado, esta arquitectura referencial se denomina ARXX y es el estándar de desarrollo de sistemas en Java. Actualmente existen diferentes servidores de aplicaciones (Jboss y Weblogic) como contenedores de aplicaciones Java, lo anterior se debe a que la arquitectura estándar ha tenido demasiadas iteraciones, pero tienen similitud en los procesos para la ejecutar las instalaciones de componentes en los ambientes pre productivos y productivos. A continuación, se detalla el deployment en esto dos servidores de aplicaciones. Weblogic:

1. El programador una vez que ha terminado el desarrollo de acuerdo al requisito de negocio, compila el fuente,

lo versiona y crea un tag para ser desplegado en los ambientes pre productivos. 2. Genera un Jira al Área de Middleware para que la versión generada sea instalada en estabilización. En el

Jira se identifica el sistema o aplicación que se requiere instalar, la versión del componente y si los componentes corresponden a negocio (backend) o aplicativo (frontend). Si la persona de Middleware al realizar el deployment se encuentra con errores comenta el Jira para notificar al programador.

3. El programador realiza el testing ingresando a la aplicación en estabilización sin revisar los cambios

requeridos por el negocio, solo se verifica que el deployment funcione correctamente. 4. Si no se encuentran errores en el ambiente de estabilización el programador crea un Jira al Área de

Middleware para instalar la aplicación en certificación, mencionando nuevamente el sistema, la versión y el tipo de componentes (backend y/o frontend).

5. Antes de realizar el despliegue a certificación la persona de Middleware toma el fuente según la versión

indicada en el Jira por el programador, compila, sube el artefacto al servidor de integración y por último lo despliega en los ambientes de certificación

6. Una vez notificado al programador que la instalación ha sido exitosa en certificación, se informa al usuario

del negocio para que realice las pruebas de los cambios solicitado. Si el usuario no encuentra errores notifica al jefe de proyecto para que la corrección de error o mejora del sistema sea pasada a producción, de lo contrario informa sobre los errores encontrados, el programador corrige la aplicación y vuelve al punto 1.




13

Figura 7. Fuente Propia: “BPMN Proceso Instalación Ambiente Weblogic”.

Jboss:

La instalación de componentes en Jboss sigue el mismo procedimiento que Weblogic, la única diferencia es que el artefacto es subido al servidor de integración por el programador antes de enviar el Jira a estabilización a Middleware. En este proceso la persona de Middleware no tiene que compilar la versión cómo lo hace en Weblogic, solo tiene la responsabilidad de desplegar el artefacto en los ambientes.

Figura 8. Fuente Propia: “BPMN Proceso Instalación Ambiente Jboss”.




14

Observaciones en la Instalación de Componentes Java:

- Se estableció que Middleware tienen un delta de tiempo 4 horas para la instalación de componentes desde que es recibido el Jira en Middleware.

- El Jira que se envía en la etapa de instalación en estabilización tienen la misma información que la etapa de

instalación en certificación, solo cambia el ambiente. - Los despliegues de componentes se realizan en forma manual. - El testing unitario lo realiza el programador ingresando a las aplicaciones modificadas. - Existen diferencias en los procesos de instalación para los distintos servidores de aplicaciones.

3.1.2. ASP y C:

Existen sistemas en ASP y C en la Unidad Tecnológica debido a dos motivos, sistemas adquiridos por compra directa o sistemas legacy. La instalación de componentes es mucho más simple para el programador ya que tiene el control de los ambientes pre productivos, no es necesario realizar Jira y Middleware no participa en este proceso. A continuación, se describe los pasos para la instalación de componentes ASP y C.

1. El programador una vez que ha terminado el desarrollo de acuerdo al requisito de negocio, compila el fuente

y lo instala directamente en certificación. 2. El programador realiza el testing unitario ingresando al sistema en certificación. 3. Si no se encuentran errores el programador informa al usuario de negocio para que realice las pruebas de

aceptación 4. Si el usuario no encuentra errores en el ambiente de certificación notifica al jefe de proyecto para que la

corrección de error o mejora del sistema sea pasada a producción y se sube los cambios al control de versiones, de lo contrario informa sobre los errores encontrados, el programador corrige la aplicación y vuelve al punto 1

Figura 9. Fuente Propia: “BPMN Proceso Instalación Ambiente ASP y C”.




15

Observaciones en la Instalación de Componentes ASP y C:

- La instalación de componentes es en forma manual. - No existe registro de instalación en los ambientes pre productivos. - El testing unitario lo realiza el programador ingresando a las aplicaciones modificadas. - El control de versiones se realiza en la última etapa del proceso. - El control de los ambientes pre productivos no debe tener control el programador.

3.1.3. Proceso de Instalación en Producción

El proceso de instalación de componentes en producción es indiferente a la tecnología ocupada en los sistemas y es transversal en todas las áreas de desarrollo, difiere solo en lugar en donde se tiene que obtener el componente a instalar de acuerdo a la tecnología de desarrollo. A continuación, se explica el proceso:

1. Una vez que es recibido la aceptación de desarrollo por parte del usuario de negocio el programador debe crear el Jira Solicitud Actividad Programada (SAP). En este Jira se especifica la versión del componente a instalar, el sistema comprometido y hora y fecha tentativa de instalación del componente.

2. Como segundo paso el programador tiene que crear el Jira Registro de Evidencia de certificación (REC), en

donde se tiene que especificar las pruebas de aceptación realizadas, el ciclo de errores de acuerdo a los test realizados y evidenciar la aceptación conforme por parte del usuario de negocio. Este REC es aprobado por el área de calidad de informática.

3. Una vez que estos Jira con su respectiva documentación son aprobados por el área de producción (ADP) se

fija la fecha y hora real de instalación. 4. Dependiendo de la arquitectura y el lenguaje del sistema de instalar o actualizar es donde el ejecutivo de

ADP asignado toma la versión del componente mencionado en el SAP:

- WebLogic: Servidor de integración Bamboo - Java: Servidor de integración Jboss On - ASP y C: Control de versiones Harvest

Figura 10. Fuente Propia: “BPMN Proceso Instalación Producción”.




16

Observaciones en el Proceso de Instalación en Producción:

- El ejecutivo de ADP es exclusivo para cada tecnología (ASP, Java. C), tiene que tener experiencia de acuerdo a la complejidad del sistema que se requiere actualizar o instalar.

- Cierta información incluida en los Jira no se explota. Por ejemplo, en el REC se debe informar, número de

ciclos programados, pruebas ejecutada, número de errores reportados, errores solucionados y número de errores pendientes. Esta información no se analiza y no se genera un feedback a los equipos de desarrollo.

- Sobreexceso de información y actividades para el paso de producción

3.2. Optimización de Proceso de Instalación de Componentes (TO-BE)

De acuerdo a las observaciones mencionadas anteriormente, con respecto a los distintos procesos de instalación de componentes, existen importantes oportunidades de mejora al desarrollar el concepto de Lean Thinking y aplicando la metodología de Entrega Continua. Según lo analizado existen cinco grandes problemas:

1. Tareas manuales en los procesos de instalación de componentes. 2. Repetición de tareas dentro de los procesos de instalación de componentes 3. Información que no genera valor por lo tanto debe considerarse como desperdicio. 4. Falta de registro de actividades en los procesos de instalación. 5. Diferentes carriles de instalación de componentes.

3.2.1. Lean Thinking

De acuerdo a las etapas del concepto del Lean Thinking es posible describir lo siguiente:

Especificar valor: El valor para el usuario final o negocio es obtener la corrección o mejora del sistema lo más tempranamente posible y sin errores, por lo tanto, dentro del proceso de instalación de componentes se debe definir actividades que sean lo más automatizadas posibles, pero con un “toque humano”. De lo anterior es posible definir que las actividades de instalación de componentes en los ambientes pre productivos deben ser automatizado y el paso a producción debe ser calendarizado y gestionado por ADP.

Cadena de valor: Ingeniería debe de proveer una infraestructura capaz de soportar las tareas automatizadas, Middleware definir, instalar y mantener los softwares necesarios para la automatización de instalación de componentes (DevOps) y los desarrolladores utilizar la plataforma definida por Middleware.

Figura 11. Fuente Propia: “Cadena de valor”

Establecer el Flujo:

En el proceso de instalación de componentes actual es posible analizar que existen demasiadas actividades, múltiples personas involucradas y diferentes formas de instalación de componentes. De acuerdo a la metodología de Lean Thinking, cada una de estas actividades deben entregar un valor agregado y además




17

eliminar las tareas consideradas como desperdicio o que no generen un valor agregado al usuario y al proceso completo.

Por lo tanto, se definirá un flujo que sea ágil en que cada una de las actividades sea lo más automatizada posible, sin perder de vista el objetivo final y de manera transversal y homogénea en que sin importar la tecnología en que fue construido el sistema utilice el mismo flujo de instalación de componentes. A continuación, se describe el flujo ágil incluyendo el proceso de paso a producción y usando el servidor de Entrega Continua.

1. El programador una vez que ha terminado el desarrollo de acuerdo al requisito de negocio, sube el fuente al

control de versiones. 2. El servidor de Entrega Continua detecta el cambio en el control de versiones, toma el fuente, compila, lo

despliega en los ambientes pre productivos y realiza los test unitarios. 3. El servidor de Entrega Continua informa si existe errores en el despliegue en los ambientes pre productivos

al desarrollador y vuelve al punto 1, si no existen errores el desarrollador informa al usuario de negocio para las pruebas de aceptación.

4. Si el usuario no encuentra errores en el ambiente de certificación notifica al jefe de proyecto para que la

corrección de error o mejora del sistema sea pasada a producción. 5. Desarrollador debe crear el Jira Solicitud Paso a Producción (SPP). En este Jira se especifica la versión del

componente a instalar, el sistema comprometido, la evidencia de certificación y la hora y fecha tentativa de instalación del componente.

6. Una vez que el Jira SPP con su respectiva documentación son aprobados por el área de producción (ADP)

se fija la fecha y hora real de instalación. 7. El ejecutivo de ADP en el momento de instalar el componente de producción lo realiza directamente desde

el servidor de Entrega Continua.

Figura 12. Fuente Propia: “BPMN Proceso Instalación Ágil en Producción”.




18

Mejoras Aplicadas en el Nuevo Flujo:

- El servidor de Entrega Continua se encargará de los procesos de instalación en todos los ambientes. En los ambientes pre productivos será en forma automática cuando encuentre un cambio en el sistema de control de versiones, el cual tendrá las tareas de compilar, ejecutar pruebas unitarias e instalar en los ambientes de estabilización y certificación. En los ambientes de producción la instalación será de forma manual desde el servidor de Entrega Continua gatillado por el ejecutivo de ADP.

- Se eliminan los Jiras de instalación en los ambientes pre productivos al ser automatizado por el servidor de

Entrega Continua. Estos softwares proveen de informes potentes para tener un análisis entorno a los deployments.

- Middleware sólo se tendrá la responsabilidad de mantener los servidores de aplicación y de Entrega

Continua, ya sea en términos de actualizaciones de software, librerías, arquitectura de software, etc. No será responsable de la instalación de componentes, si tendrá que prestar soporte si es que alguna de las instalaciones tiene problema relacionado al servidor de aplicación y no a la programación.

- La Solicitud de Actividad Programada (SAP) y el Registro de Evidencia de Certificación (REC) son

fusionados en un solo Jira llamado Solicitud Paso a Producción (SPP). El SPP tendrá la información del SAP y REC solo que se elimina la información mencionada en el punto dos de las “Observaciones en el Proceso de Instalación en Producción” ya que es considerada como desperdicio.

Definir el “Pull”: El componente entrará al flujo de instalación en los ambientes en forma automática cuando el desarrollador realice un commit en el control de versiones e instalará sólo en ambientes pre productivos. Cuando sean aprobadas las pruebas de aceptación por el usuario de negocio, el ejecutivo de ADP terminará el flujo gatillando en forma manual la instalación en producción.

Perseguir la perfección: Las herramientas que proveerán los softwares relacionados con la Entrega Continua permitirán realizar un análisis completo de los deployment hechos en los ambientes pre productivos y productivos. Esta información puede ser procesada y darnos a conocer qué está pasando con los deployment actualmente y cómo es posible mejorar las futuras liberaciones. Lo anterior mencionado es de los puntos más importantes para mejoramiento continuo del proceso de instalación.

3.2.2. Entrega Continua

La Entrega Continua apunta a la construcción, testeo, y liberación del software de forma más rápida y más frecuente. Este enfoque ayuda en la reducción del costo, tiempo, y riesgo de la liberación de versiones a través de la liberación de versiones más incrementales a aplicaciones en producción.

De acuerdo al nuevo flujo definido en el punto de Lean Thinking, el servidor de Entrega Continua se llevará gran parte de las actividades que anteriormente eran ejecutadas por personas. Con lo mencionado anteriormente es posible mejorar considerablemente los tiempos una vez que el componente entra al proceso de instalación.

A continuación, se presenta las tareas que ejecutará el servidor de Entrega Continua para la instalación de componente tanto en los ambientes pre productivos y productivos.

1. Built: El servidor de Entrega Continua toma el fuente desde el control de versiones cuando detecta un cambio, compila el fuente para los componentes en Java y C, en ASP solo toma el fuente y genera un nuevo Tag con una número de versión definida por el desarrollador.

2. Unit tests: El servidor de Entrega Continua realiza la revisión de código y ejecuta las pruebas unitarias escritas por el desarrollador y si es que existen errores son informados.




19

3. Deploy to stage: El servidor de Entrega Continua realiza el despliegue del componente en los ambientes pre productivos.

4. Deploy to production: Una vez que las pruebas de aceptación son exitosas, se realiza la instalación del componente en producción.

Por lo tanto, si se realiza una vista completa del proceso de instalación de componentes se tendría la siguiente figura con respecto a la Entrega Continua:

Figura 13. Pipeline General Entrega Continua.

Fuente: https://www.nastel.com/blog/devops-continuous-integration-vs-continuous-delivery-vs-continuous-deployment

Los pipelines que se crearán en el servidor de Entrega Continua deben de seguir la estructura de la figura 13. Cada uno de los sistemas tendrá su propio pipeline creado en el servidor de Entrega Continua para realizar el despliegue en los ambientes, pero con ciertas diferencias en las configuraciones de las etapas dependiendo del lenguaje Java, ASP o C y la infraestructura en que se encuentran instaladas las aplicaciones.

4. Implementación de Entrega Continua

Para implementar la metodología de Entrega Continua se apoyará en softwares que proveen la facilidad de ejecutar análisis de código, pruebas unitarias y despliegue de componentes de forma automática. Es importante que las herramientas de software elegidas para la implementación tengan ciertas dependencias, configuraciones, complementos (plugins) y sean lo más integradas posible entre ellas para desarrollar cada uno de los pipelines. Con respecto al punto anterior se investigaron y analizaron varias herramientas de softwares que proveen la implementación de Entrega Continua y de acuerdo a experiencias, tiempo en el mercado, comunidad activa, flexibilidad y complementos desarrollados para la integración con otras herramientas se eligieron los siguientes softwares:

- SVN (Subversión): Es la herramienta que actualmente se ocupa en la Unidad Tecnológica para control de versiones de las aplicaciones

- Jenkins: Es el orquestador de los demás softwares que se utilizaran para la Entrega Continua y es donde se

definen y crean los pipelines con sus respectivas etapas - SonarQube: Software especializado en el análisis de código y la salud de un componente. - Puppet: Herramienta utilizada para el despliegue de componentes.

A continuación, se explicarán los softwares elegidos y la importancia dentro del proceso de instalación de componentes. Cada uno de estos softwares tiene una función específica dentro de cada etapa del pipeline y serán orquestadas por el software de Entrega Continua Jenkins.




20

4.1. Herramientas de Entrega Continua

4.1.1. Subversion

Apache Subversion (SVN) es una herramienta de control de versiones open source basada en un repositorio cuyo funcionamiento se asemeja al de un sistema de ficheros. Es software libre bajo una licencia de tipo Apache/BSD. Utiliza el concepto de revisión para guardar los cambios producidos en el repositorio. Entre dos revisiones sólo guarda el conjunto de modificaciones (delta), optimizando así al máximo el uso de espacio en disco. SVN permite al usuario crear, copiar y borrar carpetas con la misma flexibilidad con la que lo haría si estuviese en su disco duro local. [12].

La estructura TTB es el estándar en los repositorios SVN y corresponde a las iniciales de las tres carpetas que componen el primer nivel de directorios del repositorio: Trunk, Tags y Branches. A continuación, se listan las funcionalidades que se le debería dar a cada rama del repositorio:

Trunk : Rama de desarrollo principal. Tags: Rama de gestión de versiones. Reservado para versiones cerradas, por tanto, no se desarrollará sobre esta rama. Branches: Rama con evoluciones paralelas al Trunk.

Subversion permite la modificación paralela de código del repositorio, por lo tanto, trabajo en equipo, de modo que varias personas pueden trabajar de forma simultánea sobre cualquier parte del código sin crear interferencias. En el caso de que dos desarrolladores tengan que modificar el mismo elemento a la vez, Subversion integrará los cambios de forma automática, obligando al usuario a hacerlo de forma manual sólo en casos en los que el conocimiento humano sea el único que puede asegurar la correcta integración.

4.1.2. Jenkins

Jenkins es una aplicación multiplataforma, de Integración Continua y Entrega Continua que tiene como fin aumentar la productividad. Está basado en el proyecto Hudson, creado por Kohsuke Kawaguchi, que trabajaba en Sun. Unos años después de que Oracle comprara Sun, la comunidad de Hudson decidió renombrar el proyecto a Jenkins y migrar el código a Github para transformarse en Open Source.

Jenkins permite definir tareas para integrarse con herramientas de control de versiones (CVS, Subversion, Git u otros) y ejecutar proyectos basados en Apache Maven, Apache Ant, Microsoft MSBuild, shell y batch scripts de Microsoft Windows. Además, permite ejecutar tareas adicionales previo y posterior a la compilación como preparar el entorno, realizar un despliegue o compactar, subir componentes, etc.

Jenkins posee un historial de cambios realizados en cada build, muestra el usuario que ejecutó el pipeline, los archivos o componentes que fueron desplegados junto con los tiempos de ejecución, y los comentarios realizados por el usuario. Lo anterior permite realizar análisis sobre los deployment ejecutados por los desarrolladores y la calidad de software que entregan.

Actualmente existe una larga lista de complementos (plugins) desarrollados por la comunidad de Jenkins que pueden ser configurados para la integración con otras herramientas de software con el motivo de generar pipelines lo más automatizado posible.

4.1.3. Jenkins Pipelines

Jenkins Pipeline es un conjunto de complementos que permite implementar e integrar entregas continuas en Jenkins. Un pipeline de Entrega Continua es una expresión automatizada del proceso para obtener el software desde el control de versiones y hasta los usuarios finales. Cada cambio del aplicativo en el control de versiones pasa por un proceso complejo para ser instalado.




21

Este proceso implica que la construcción del software sea de una manera confiable y repetible, así como la progresiva compilación del software a través de múltiples etapas de prueba para su instalación. Jenkins proporciona un extenso conjunto de herramientas para modelar de simples a complejos pipelines "como código" a través de la sintaxis del lenguaje Pipeline domain-specific language (DSL).

La definición de un pipeline se encuentra escrito en un archivo de texto llamado Jenkinsfile que a su vez puede ser incluido en el repositorio de control de origen de un proyecto. Esta es la base de "Pipeline-as-code" tratar el pipeline como una parte de la aplicación para ser versionado y revisado como cualquier otro código [13]. Al modelar una serie de tareas relacionadas, los usuarios pueden aprovechar las siguientes características:

Código: Implementan en código y, por lo general, se manejan en el control de origen de versiones, lo que les permite a los desarrolladores editar, revisar e iterar en su canal de distribución.

Durable : Pueden sobrevivir a los reinicios planificados y no planificados del maestro Jenkins.

Pausable: Pueden detenerse y esperar la entrada o aprobación de una persona antes de continuar con la ejecución de la siguiente etapa del pipeline.

Versátil: Soportan requisitos complejos de Entrega Continua, incluido la capacidad de unir / unir, buclear y realizar trabajos en paralelo.

Extensible: Los complementos (plugins) admite extensiones personalizadas y múltiples opciones para la integración con otros complementos.

4.1.4. SonarQube

SonarQube es una plataforma de código abierto desarrollada por SonarSource para la inspección continua de la calidad del código. Es utilizado para realizar revisiones automáticas de las aplicaciones mediante el análisis estático de código fuente como Checkstyle, PMD o FindBugs para detectar errores y vulnerabilidades de seguridad en más de 20 idiomas de programación. SonarQube ofrece informes sobre códigos duplicados, estándares de codificación, pruebas unitarias, cobertura de códigos, complejidad del código, comentarios, errores y vulnerabilidades de seguridad. SonarQube puede registrar el historial de métricas y proporciona gráficos de evolución. SonarQube proporciona análisis e integración totalmente automatizados con Maven, Ant, Gradle, MSBuild y herramientas de Integración Continua (Atlassian Bamboo, Jenkins, Hudson, etc.).

4.1.5. Puppet Enterprise

Puppet es una herramienta software de automatización que ayuda a gestionar el ciclo de vida de la infraestructura, desde el aprovisionamiento y hasta el informe de orquestación. Usando Puppet se pueden automatizar tareas repetitivas, hacer despliegue de aplicaciones y gestionar los cambios en una infraestructura cloud. Puppet usa un modelo declarativo para la automatización IT. El ciclo de vida de Puppet, que está compuesto por los siguientes pasos:

1. Se define el estado deseado de la configuración de la infraestructura, usando el lenguaje declarativo de Puppet (basado en Ruby).

2. Se simulan los cambios en la configuración antes de su aplicación 3. Se despliegan los cambios en la infraestructura, corrigiendo los posibles desvíos de las configuraciones. 4. Se informa de los cambios entre el estado actual y el estado deseado, así como también de las acciones a

tomar para pasar de un estado al otro.




22

4.2. Integración de las Herramientas de Entrega Continua

Como se mencionó anteriormente, Jenkins es el orquestador de la automatización de los procesos de instalación en los ambientes pre productivos y que integrará los softwares de Entrega Continua mediante complementos (plugins) desarrollados para la comunicación entre los diferentes sistemas. A continuación, se presenta un esquema del funcionamiento integrado de los softwares:

Figura 14. Fuente Propia: Esquema de Integración Softwares Entrega Continua.

4.3. Laboratorio de Investigación

Para la validación de la hipótesis se montó un laboratorio con máquinas virtuales para instalar los softwares de Entrega Continua y además se configuraron los complementos de Jenkins para la integración. A continuación, se detallan los softwares instalados:

- Centos 7: Sistema operativo Linux. - Jenkins v2.121.2: Software de Entrega Continua.

- Svnkit v1.9.3: Plugin para la integración con SVN. - SonarQube Scanner v2.8: Plugin para la integración con SonarQube. - rtyler-jenkins v1.7.0: Plugin para la integración con Puppet Enterprise.

- Puppet Enterprise v5.5.3: Software para el deployment de aplicaciones. - SonarQube v7.3: Software para calidad de código continuo. - VmWare Workstation 14 Player: Software de virtualización de servidores.

La configuración de cada uno de los softwares fue básica ya que lo que se requiere demostrar dentro de la hipótesis es la velocidad de despliegue al usar el enfoque de Entrega Continua y la realidad de la organización es mucho más compleja en relación a los parámetros configurados (infraestructura, ambientes, servidores de aplicación, etc.)

5. Resultados Obtenidos

5.1. Resultado de la Situación Actual

De acuerdo a los procesos descritos en el punto 3.1 se tomó como prueba cuatro aplicaciones, una por cada carril de instalación y tecnología usada (C, ASP, Java Weblogic y Jboss).




23

Escenarios:

- Los tiempos de instalación de componentes en los ambientes pre productivos en las aplicaciones escritas en ASP y C no tienen registros debido a que los mismos desarrolladores son los encargados de la instalación, por lo tanto, se tomó el tiempo a base de experiencias de 4 usuarios.

- Los tiempos de instalación de componentes en los ambientes pre productivos en las aplicaciones escritas en

Java (Jboss y Weblogic) fueron obtenidas en base a 20 de reportes de resolución de incidencias Jira enviadas a Middleware quienes son los encargados de las instalaciones.

- Las aplicaciones escritas en ASP y C no tienen ambientes de estabilización. - El SLA de Middleware para la instalación de componentes es de 4 horas y se omitieron los casos que fueron

realizados al siguiente día de la creación del Jira. - Se descartó los tiempos de instalación de componentes en los ambientes productivos ya que son

programadas y no tiene registro exacto del inicio y término de la actividad

A continuación, se presenta una tabla con los tiempos de instalación de componentes en los ambientes pre productivos recopilados de acuerdo a los escenarios descritos anteriormente:

Tabla 4. Fuente Propia: Tiempos de instalación de componentes en ambientes pre productivos.

Como se puede visualizar en la tabla 4 los tiempos difieren considerablemente en la instalación de componentes de las aplicaciones desarrolladas en ASP y C en relación con Java.

Lo anterior se debe a que la instalación de los componentes Java son ejecutadas por terceras personas (Middleware) en donde no tienen el 100% de disponibilidad a esta tarea. Esto conlleva a un retraso considerable en las entregas de productos (mejoras o corrección de errores) a los usuarios finales. A diferencia de ASP y C los tiempos son bajos al ser ejecutadas las tareas por el mismo desarrollador, pero no existe un control o registro en la instalación de componentes.

Los tiempos del análisis de código de componentes C, ASP en comparación con Java difieren ya que este último son archivo JAR que contienen múltiples archivos empaquetados de Java, en cambio las otras aplicaciones son archivos únicos.

5.2. Resultado de la Entrega Continua

De acuerdo a los procesos descritos en el punto 3.2 en la optimización del proceso de instalación de componentes, se configuraron los 4 carriles de instalación (C, ASP, Java Weblogic y Jboss) en el servidor de Entrega Continua.

Escenarios:

- Las configuraciones realizadas en el laboratorio de Entrega Continua son básicas y no fueron realizadas sobre los ambientes pre productivos que existen en la Unidad Tecnológica, aun así, en el laboratorio se trató de replicar lo actual. Por ejemplo, los ambientes de estabilización y certificación actuales están granjeadas, pero para efectos de la validación de la hipótesis se configuraron los servidores de estabilización y certificación en máquinas virtuales.




24

- Para tener una mayor estimación en los tiempos de instalación de componentes en los ambientes pre productivos en el servidor de Entrega Continua se ejecutaron 10 pruebas por cada pipeline configurado.

- Cada uno de los softwares mencionados en el punto 4.1 fueron instalados en varias máquinas virtuales dentro

de un PC por lo que el rendimiento podría afectar los tiempos de instalación. - En el despliegue de componentes se utilizaron las mismas aplicaciones que en el punto 5.1 para tener una

comparación en los tiempos de instalación.

A continuación, se presenta una tabla con los tiempos de instalación de componentes usando el servidor de Entrega Continua:

Tabla 5. Fuente Propia: Tiempos de instalación de componentes en el servidor de integración.

5.3. Comparación de Resultados

Comparando las tablas 4 y 5 se visualiza que los tiempos de instalación en general bajaron considerablemente en las aplicaciones Java debido a que la instalación es ejecutada automáticamente en los ambientes pre productivo.

Los tiempos de compilación de las aplicaciones en general aumentó en forma mínima en las pruebas realizadas debido a que el servidor de Entrega Continua cada cierto tiempo busca cambios en el repositorio de fuentes para realizar la tarea de compilación, al contrario de la forma actual, en el cual el desarrollador compila inmediatamente al terminar su fase de desarrollo.

A continuación, se presenta la tabla comparando los resultados de la situación actual con el laboratorio de Entrega Continua:

Tabla 6. Fuente Propia: Resultados Finales.

En la tabla 6 se refleja una comparativa entre los resultados de la situación actual junto con el laboratorio de Entrega Continua en donde el porcentaje de mejora en los tiempos son considerables. Se puede visualizar que los tiempos en la instalación de aplicaciones Java mejora en un 95% y los demás lenguajes en un 65% siendo que dentro de los carriles configurados se agrega la etapa de análisis de código. Si ampliamos la información recogida en términos de un rango de tiempo de un año de instalación de componentes en los sistemas ASP y C, en donde se realizan en promedio entre dos instalaciones por mes por cada sistema y el área interna administra alrededor de catorce sistemas activos, tenemos los siguientes resultados:




25

Tabla 7. Fuente Propia: Resultados Ampliados en Sistemas Legacy.

6. Conclusiones

Es de vital importancia mejorar los procesos internos usando la metodología de Lean Thinking y aumentar los tiempos de entregas de mejoras y corrección de errores de los sistemas usando la metodología de Entrega Continua. Las actividades que se ejecutan dentro de los procesos deben ser ser lo más eficiente posible eliminado la información que no genera valor y la automatización de las actividades de los procesos son críticos para entregar resultados a los usuarios finales de forma rápida y sin errores.

Con respecto a la hipótesis se menciona que mejorarán los tiempos de instalación de componentes en un 70% con la propuesta de solución y se puede visualizar en la tabla 6 que los tiempos usando solo la metodología de Entrega Continua puede mejorar en un rango de [65%-95%]. Por lo tanto, se concluye que la hipótesis es válida.

Los resultados de la investigación en los sistemas legacy se ven mejorados cuando ampliamos los rangos de instalación a un año, podemos notar en la tabla 7 el tiempo que nos ahorramos al implementar la Entrega Continua, además existe la ganancia de tener registros de instalación en los ambientes de certificación y medir la calidad de código.

Es importante considerar también los tiempos que se reducen al optimizar los procesos de negocio mediante el Lean Thinking para la instalación de componentes, si bien no es posible medir estos procesos de forma exacta si son importantes para eliminar los procesos o información que no generan valor y por ende agilizar los pasos en producción.

Por lo tanto, es posible concluir que las buenas prácticas, la eliminación del desperdicio de la información, la automatización de procesos y la centralización de la plataforma de instalación de componentes aumentarán la productividad y la entrega de mejoras y corrección de errores hacia los usuarios finales.

7. Trabajo Futuro

Los siguientes pasos a seguir es dar a conocer a la alta dirección de la Unidad Tecnológica para toma de conocimiento y convencimiento que las metodologías de Lean Thinking y Entrega Continua detalladas en este informe son efectivas para mejorar el ciclo de desarrollo de software específicamente el proceso de instalación de componentes.

Una vez aprobado este informe se procederá a implementar los nuevos flujos de proceso definido en el Lean Thinking y luego habilitar una plataforma robusta para la implementación de la Entrega Continua instalando los softwares y plugins necesarios, respetando las versiones mencionadas en el informe.

La configuración de los softwares se realizará de acuerdo a los estándares de la Unidad Tecnológica y la complejidad que tienen actualmente los servidores de estabilización y certificación en términos de accesos, alta disponibilidad y escalabilidad.

Como plan para utilizar los softwares de Entrega Continua se crearán pipelines en los sistemas que administra el Departamento Transversal específicamente en el Área Interna de la Unidad Tecnológica y se realizarán capacitaciones sobre su uso. Una vez que este proceso se encuentre maduro, se irá implantando en las demás áreas de desarrollo restantes.




26

Referencias

[1] Bronwyn Smith. http://elmotalent.com.au/news/2016/05/how-to-develop-effective-kpis/ [2] B. Fitzgerald and K. Stol: Continuous Software Engineering and Beyond: Trends and Challenges, Value and Waste,

RCoSE 2014 [3] Shailesh Panth. https://www.bizmanualz.com/make-your-business-lean/what-is-lean-thinking.html [4] B. Fitzgerald and K. Stol: Continuous Software Engineering and Beyond: Trends and Challenges, Autonomation and

Building-in Quality, RCoSE 2014 [5] Amazon Web Services. https://aws.amazon.com/es/devops/continuous-delivery/ [6] B. Dlugi and K. Krcmar: Model-Based Performance Evaluations in Entrega Continua Pipeline, CONTINUOUS

INTEGRATION, DELIVERY & DEPLOYMENT, QUDOS 2015 [7] J. Humble and D. Farley. Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment

Automation. Addison-Wesley Professional, 1st edition, 2010. [8] "Daemonite: The science of version numbering". 2004-09-14. Retrieved 2009-04-11. [9] Peterson, Jim, Roland Smith, Ph.D. The 5S Pocket Guide (Portland, Oregon: Productivity Press,1998). [10]Shailesh Panth. https://www.bizmanualz.com/make-your-business-lean/what-is-lean-thinking.html [11]Productivity Press Development Team. 5S for Operators: 5 Pillars of the Visual Workplace (Portland, Oregon:

Productivity Press, 1996). [12] https://es.wikipedia.org/wiki/Subversion_(software) [13] https://jenkins.io/doc/book/pipeline/ [14] https://es.wikipedia.org/wiki/DevOps [15] https://es.atlassian.com/devops [16] Turnbull J; McCunePro J; "Puppet (Expert's Voice in Open Source)" 1a edición. Nueva York (USA). Apress, 2011.

Implementación de Entrega Continua en los Sistemas ... · universidad técnica federico santa...

Documents

Transcript of Implementación de Entrega Continua en los Sistemas ... · universidad técnica federico santa...