UNIVERSIDAD NACIONAL DEL CENTRO DE LA PROVINCIA DE BUENOS AIRES

FACULTAD DE CIENCIAS EXACTAS

TESIS DE GRADO DE INGENIERIA DE SISTEMAS

Despliegue automatico multiplataforma para aplicaciones deEscritorio

por

Nicolas Sebey

Dr. Mauricio Arroqui

Director

Ing. Sebastian Sampaoli

Co-director

Tandil, Mayo de 2021

Agradecimientos

Se agradece en primer instancia al director de esta tesis Dr. Mauricio Arroqui y al co-director

Ing. Sebastian Sampaoli por posibilitar, compartir y colaborar en la realizacion de este trabajo

final. El mismo simboliza el final de una larga carrera, que no habrıa sido posible sin el apoyo

de nuestros seres queridos. Un particular agradecimiento a nuestros amigos facu, lauta y franco

con los que compartimos este largo camino academico y personal, de estudio y andanzas. A los

jurados, por dedicar parte de su tiempo a leer esta tesis.

Se agradece especialmente a la familia que forjo su caracter y cuyas ensenanzas lo acompanan dıa

a dıa, sus padres Carlos y Marıa Alicia, y sus hermanos Juan Pablo y Rodrigo. Como no agradecer

a su grupo de amigos de toda la vida que lo acompanaron en todo momento a la distancia kiri,

enzo, mati, juanma, ber, agus, cote, manu, joaco y fer. A sus companeros de basquet que lo

ayudaron a desconectarse un poco y poder continuar con su otro amor. Tambien agradece a

todas las personas que en mayor o menor medida aportaron animo y buenas intenciones durante

la carrera.

ii

Indice general

Indice de figuras VI

1. Introduccion 1

1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Organizacion del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Contexto 7

2.1. DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Herramienta de administracion de aplicaciones: App Manager . . . . . . . . . . 12

2.2.1. Uso de App Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Instaladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1. Herramientas para generar un instalador en Windows . . . . . . . . . . . 15

2.3.2. Herramientas para generar un instalador en Linux . . . . . . . . . . . . . 16

2.3.3. Herramientas para generar un instalador en MacOs . . . . . . . . . . . . . 16

2.3.4. AD-HOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3. Enfoque 19

3.1. Problematicas para el despliegue de aplicaciones de escritorio . . . . . . . . . . . 20

3.1.1. Crear y mantener pipeline IC/DC . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2. Distribuir la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iii

INDICE GENERAL iv

3.2. DevOps por App Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1. Crear y mantener pipeline IC/DC . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2. Distribuir aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3. Abstraer App Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4. Diseno e implementacion 30

4.1. Diseno e implementacion del soporte para el despliegue de aplicaciones . . . . . . 30

4.1.1. Diseno e implementacion en App Manager . . . . . . . . . . . . . . . . . . 31

4.1.1.1. Diseno e implementacion del Cliente . . . . . . . . . . . . . . . . 31

4.1.1.2. Diseno e implementacion del servidor . . . . . . . . . . . . . . . 32

4.1.2. Diseno e implementacion del Instalador . . . . . . . . . . . . . . . . . . . 38

4.2. Instanciacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1. App Manager para WPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.2. Instalador para WPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5. Resultados experimentales 52

5.1. Implementacion manual de DevOps para una aplicacion WPF . . . . . . . . . . 52

5.2. Utilizacion de App Manager para una aplicacion WPF . . . . . . . . . . . . . . . 55

5.3. Comparacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6. Conclusiones 59

6.1. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Bibliografıa 63

Indice de figuras

2.1. Vista de registro de la plataforma. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2. Vista de la plataforma correspondiente a la creacion de aplicaciones . . . . . . . 13

2.3. Vista del formulario a completar para crear una aplicacion. . . . . . . . . . . . . 13

2.4. Vista de menu de una aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5. Vista de la carga del repositorio a la plataforma . . . . . . . . . . . . . . . . . . . 14

2.6. Vista del estado de la aplicacion en sus diferentes branchs . . . . . . . . . . . . . 14

3.1. Aplicacion WPF desarrollada para realizar la pruebas. . . . . . . . . . . . . . . . 21

3.2. Diferentes ramas del repositorio y su estado. . . . . . . . . . . . . . . . . . . . . . 26

3.3. Evolucion esperada de App Manager. . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1. Interfaz de Usuario para la creacion de una aplicacion. . . . . . . . . . . . . . . . 32

4.2. Directorio de una aplicacion EUIJA creada mediante el CLI. . . . . . . . . . . . 33

4.3. Estructuras anadidas para la nueva solucion . . . . . . . . . . . . . . . . . . . . . 34

4.4. Interfaz gitProvider y sus implementaciones . . . . . . . . . . . . . . . . . . . . . 37

4.5. Diagrama del proyecto del instalador antes de ser modificado. . . . . . . . . . . . 40

4.6. Diagrama de secuencia instalador original. . . . . . . . . . . . . . . . . . . . . . . 41

4.7. Diagrama actualizado del proyecto instalador. . . . . . . . . . . . . . . . . . . . . 43

4.8. Importacion de los diferentes archivos en el proyecto. . . . . . . . . . . . . . . . . 44

4.9. Diagrama de secuencia del proyecto modificado. . . . . . . . . . . . . . . . . . . . 45

4.10. Estructura de un mensaje. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.11. Etapa de descarga del instalador auto generado. . . . . . . . . . . . . . . . . . . 47

v

INDICE DE FIGURAS vi

4.12. Diagrama de clase de la instanciacion a WPF. . . . . . . . . . . . . . . . . . . . . 50

5.1. Instalador creado mediante Visual Studio Installer . . . . . . . . . . . . . . . . . 54

5.2. Ventana creacion nueva aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3. Menu de una aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4. Conexion de un repositorio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.5. Build history de una aplicacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Nomenclatura

Branch Del ingles branch. Representa una linea de desarrollo distinta de la principal.

CEF Del ingles Chromium Embededd Framework.

CLI Del ingles Command line interfaces.

DC Distribucion Continua.

DevOps desarrollo y operaciones.

EUIJA Enriched UI Java Application

Force Push Del ingles Force push. Este comando sobrescribe toda la estructura y secuencia de

commits en el repositorio central, tirando a la basura los commits de las demas personas.

IC Integracion Continua.

msi Microsoft installer

Request Del ingles request. Representa una solicitud de respuesta por parte del usuario.

SO Sistema operativo.

Space Del ingles Space. Un space es un servidor que nos permite almacenar una amplia cantidad

de contenido estatico sin estructura.

Trait Del ingles Trait. Los traits son una lista de metodos con o sin implementacion que las

estructuras o los tipos deben implementar para cumplir ese trait.

UI del ingles User Interface

UWP Universal Windows Applications

VCS Del ingles version control system. Sistema de control de versiones.

WIX Del ingles Windows InstalLer XML.

WPF Del ingles Windows Presentation Foundation.

vii

Capıtulo 1Introduccion

Es sabido que el desarrollo de aplicaciones de escritorio domino el mundo del software por mucho

tiempo y, a pesar de que en estos tiempos se ve relegado ante el desarrollo de aplicaciones web o

aplicaciones moviles que son las que acaparan el mercado, las aplicaciones de escritorio cumplen

un rol fundamental para el mundo del software. Esto se debe a que poseen ventajas con respecto

a otro tipo de aplicaciones como pueden ser las aplicaciones web. Por ejemplo, las aplicaciones

de escritorio suelen ser menos vulnerables en terminos de seguridad informatica, suelen tener

tiempos de respuesta mas rapidos y son mas estables.

A la hora de crear una aplicacion de escritorio el enfoque no debe hacerse solamente en el desa-

rrollo en sı, sino que se debe seguir y respetar el ciclo de vida por el que pasa una aplicacion.

Este consta de 6 partes: (I) Planeamiento; (II) Diseno del programa; (III) Verificacion y valida-

cion; (IV) Codificacion de la aplicacion; (V) Despliegue; (VI) Retiro de la aplicacion. En cada

una de estas partes se responden a preguntas que deben hacerse los desarrolladores y se toman

decisiones que daran forma a la aplicacion. Por ejemplo, la eleccion de las tecnologıas de desa-

rrollo, como se distribuira la aplicacion, como se actualizara la aplicacion desde la perspectiva

del cliente, entre otras decisiones necesarias.

La fase de despliegue es clave a la hora de tener una aplicacion lista para el mercado, durante

esta fase se deben definir ciertas caracterısticas de su aplicacion. Se debe testear el codigo para

asegurarse que lo que se este por entregar funcione de la manera correcta. Se debe elegir un

medio de instalacion que se encargue de la instalacion. Empaquetando todo lo necesario para

que la aplicacion funcione dentro de cualquier maquina que cumpla con los requisitos mınimos

para utilizar la aplicacion. Este instalador puede ser generado mediante alguna herramienta pre-

existente o puede realizarse desde cero generando el codigo fuente del mismo. Se debe decidir

como se distribuira la aplicacion y por donde ya que puede ser mediante mercados de aplica-

ciones, mas conocidos como “Market Place”, tanto de los diferentes sistemas operativos como

otros existentes. O se puede distribuir de manera directa por el desarrollador o la empresa que

desarrolle la aplicacion.

Hace algunos anos para facilitar el desarrollo y el despliegue de aplicaciones surgio un nuevo

1

CAPITULO 1. INTRODUCCION 2

concepto para implementar, DevOps. El termino DevOps nace de la combinacion de las palabras

desarrollo y operaciones. Este juego de palabras ya sirve para dar una idea de la naturaleza

del termino. Es una practica donde la colaboracion entre diferentes disciplinas del desarrollo

de software es alentada [21]. Implementa una serie de conceptos modernos que sirven para la

optimizacion del despliegue de aplicaciones y son partes fundamentales del desarrollo de DevOps

como contenedores, Integracion Continua, Distribucion Continua, entre otros.

1.1. Motivacion

Una aplicacion debe ser desarrollada y entregada al cliente de manera optima. Para esto se

debe seguir y respetar el ciclo de vida de la misma. El ciclo de vida de una aplicacion esta

compuesto por seis fases. La fase de planeamiento, donde se identifican las necesidades del cliente,

la propuesta de mercado y se plantean propuestas de producto; la fase de diseno y desarrollo,

donde se especifican los requerimientos del producto (caracterısticas, funcionalidades, legales); la

fase de verificacion y validacion, donde se crean prototipos para verificar y validar funcionalidad,

ambiente, confiabilidad, regulaciones y diferentes aspectos mas especıficos de cada producto; la

fase de produccion, donde se desarrolla el producto; la fase de despliegue, donde se deja el

producto listo para su uso, esta fase tambien abarca soporte tecnico; y la fase de retiro de la

aplicacion,cuando esta ya pasa a ser obsoleta [22].

Durante el transcurso del ciclo de vida de una aplicacion los ingenieros tomaran decisiones

que afectaran de manera directa en el producto final. En la primera fase, mientras se imagi-

na y piensa el producto, se debe decidir que tecnologıa de desarrollo utiliza. Esta se elegira

dependiendo de los requerimientos funcionales y no funcionales que debe cumplir el producto.

Se debera decidir que lenguaje de programacion se utilizara, el sistema operativo donde corre-

ra, si la aplicacion sera web o de escritorio, entre otras. Particularmente, entre las tecnologıas

mas populares para el desarrollo de aplicaciones de escritorio se encuentran Electron https://

electronjs.org/, JavaFx https://docs.oracle.com/javase/8/, Swing https://tinyurl.

com/3pyhtu9r, QT https://www.qt.io/, Universal Windows Platform https://tinyurl.com/

p3atyjs3, Windows Presentation Foundation WPF (del ingles Windows Presentation Founda-

tion) https://tinyurl.com/29dn4r4t entre otras.

Mayormente, las aplicaciones no son desarrolladas por un solo desarrollador, sino que habra un

equipo detras de cada una de ellas. Esto hace que un producto se termine en menor tiempo, pero

tambien trae consigo complicaciones. Entre las complicaciones mas frecuentes se encuentran la

sincronizacion entre desarrolladores, donde un desarrollador realiza cambios en su ambiente de

trabajo y debe compartirlos con el resto del equipo. Tambien, el testeo integral de un cambio,

donde los cambios de un desarrollador no pueden ser testeados ıntegramente por este y generan

errores en el codigo introducido por otros desarrolladores. Es por esto, que la automatizacion de

este proceso mediante herramientas de integracion continua generan un impacto positivo en la

productividad de los equipos de desarrollo [6]. Las herramientas de IC constan de un repositorio

central donde todos los desarrolladores combinan sus cambios de forma periodica realizandose

CAPITULO 1. INTRODUCCION 3

pruebas automaticas al codigo para asegurarse que estos cambios no danen ni afecten al producto

final. Durante este proceso se busca encontrar y arreglar errores con mayor rapidez, mejorar la

calidad del software y reducir el tiempo que se tarda en validar las nuevas actualizaciones [6].

El concepto anterior de IC en la mayorıa de los casos viene asociado al de distribucion continua.

Este concepto establece que los desarrolladores deben realizar cambios pequenos en el codigo en

ciclos cortos. En cada ciclo se construye, se prueba y se distribuye el codigo. Una vez realizado

esto, despues de ser aprobado, el cambio se hace visible y se le comunica a las demas partes del

equipo sobre este. Que el resultado de los testeos haya sido satisfactorio (en la IC), permite que

estos cambios sean distribuidos. Pasaran a un servidor donde seran compilados para luego ser

utilizados por las demas partes del equipo. Dicho servidor notificara sobre el resultado obtenido

de las diferentes pruebas para que luego el equipo de operaciones pueda probarlos en un entorno

de produccion [19] . De esta manera, ademas de automatizar el testeo de los cambios realizados

(IC) se logra automatizar el proceso de lanzamientos de estos (DC). Hay varias herramientas

para elegir a la hora de llevar esto a cabo, como puede ser Jenkins https://jenkins.io/ o

Azure DevOps https://azure.microsoft.com/es-es/, entre otras.

En aplicaciones de escritorio, para realizar la fase de despliegue se debe elegir la estrategia que se

va a aplicar para que el usuario obtenga la aplicacion y la mantenga actualizada. Una estrategia

conocida es en base a instaladores (gestores de paquetes). El instalador debe ocuparse de cargar

la aplicacion en la maquina del usuario ası como cualquier otro archivo o recurso que esta emplee

y necesite para su funcionamiento. El instalador debe empaquetar la aplicacion en un programa

de instalacion que luego recibira el usuario. Un paquete contiene en un formato estandarizado el

codigo fuente o el codigo compilado de un modulo de software (o el lugar donde estan alojados),

junto con su documentacion y meta data [18]. El instalador organiza y simplifica la instalacion,

gestiona el mantenimiento del software al estandarizar y organizar la produccion y el consumo

de librerıas (una librerıa es un conjunto de paquetes de software ”complementarios”. Brindan

el poder de construir, instalar y usar multiples versiones de software en el mismo sistema, sin

afectar los paquetes instalados en el lado del sistema).

A la hora de tomar la decision sobre que instalador elegir para la aplicacion se deben tener en

cuenta ciertas caracterısticas. Por ejemplo, existen herramientas que permiten anadir tecnologıas

que automatizan este proceso. Como es el caso de clickOnce https://tinyurl.com/4febebbp o

squirrel https://github.com/Squirrel/Squirrel.Windows. Estas tecnologıas automatizan el

proceso de la carga de actualizaciones. A su vez se encargan de administrar y conceder los

permisos de seguridad necesarios para poder ejecutar la aplicacion en el sistema operativo

correspondiente. Otra metodologıa que se puede utilizar es la de gestores de paquetes exter-

nos, como es el caso de InstallShield https://www.flexerasoftware.com/install/products/

installshield.html, Wix https://wixtoolset.org/, entre otros. Se debe tener en cuenta el

lenguaje de programacion que se utiliza, su costo, que tipo de empaquetado puede crear, si es

un ejecutable Windows (exe), o uno de actualizaciones de Windows , o de aplicaciones Windows

Universales. La seguridad que brindan, por ejemplo dependiendo el sistema operativo en el que

se ejecute, los permisos del mismo que debe cumplir para no violar restricciones de estos y ası

CAPITULO 1. INTRODUCCION 4

acceder a funciones especıficas de hardware y software.

Utilizar un gestor de paquetes requiere: (i) prevenir problemas de incompatibilidades con el

sistema operativo en el que vaya a ser instalado generando incompatibilidades entre bibliotecas

vinculadas dinamicamente (es decir, que las bibliotecas que se instalen para el funcionamiento

del software no violen protocolos de seguridad del sistema operativo en el que se instalen) o

con cualquier actualizacion de sistema que se realice al instalar un nuevo programa; (ii) tener

en cuenta es que algunos gestores de paquetes brindan servicios a softwares que tengan licencia

como codigo abierto; (iii) tambien el programador debe familiarizarse con el gestor, conocer su

interfaz de lınea de comandos (CLI); (iv) dependiendo del gestor que utilice el programador

debera saber que archivos debe proporcionarle a este para que genere de manera correcta el

instalador.

1.2. Tesis

Con el fin de resolver las debilidades de los enfoques actuales, la presente tesis tiene por objetivo

general realizar una herramienta de software que automatice y simplifique la fase de despliegue

de una aplicacion, para conseguir una mejora de eficacia a la hora de desarrollar aplicaciones de

escritorio. La herramienta permitira: (i) gestionar el branch que desea distribuir el desarrollador

una vez subido a su repositorio git. (ii) Generar automaticamente el pipeline IC/DC. (iii) Crear

una compilacion nueva del codigo (ya sea si es una primera version o una actualizacion). (iv)

Generar instaladores de forma automatica para distintas plataformas. Para llegar a obtener la

mejor solucion posible en el tiempo establecido se utilizara como base una herramienta preexis-

tente y se la adaptara para cumplir con el funcionamiento deseado. Dicha herramienta, es una

herramienta web llamada App Manager. Esta aplicacion, de la que se hablara en profundidad

mas adelante, se encarga de automatizar el despliegue de aplicaciones EUIJA (Enriched UI java

applications) de las que tambien se hablara mas adelante. La idea de esta tesis es poder ex-

tender la solucion a aplicaciones de cualquier tipo, como consecuencia se plantear los siguientes

objetivos.

El objetivo general se desglosa en los siguiente objetivos especıficos:

Generar una abstraccion de la herramienta existente capaz de soportar aplicaciones de

todo tipo. Esta abstraccion debera permitir que con alguna simple nueva configuracion en

App Manager para cada aplicacion, esta se vea soportada. Las tareas que se deben poder

realizar son:

• Compilar una aplicacion simplemente vinculandola a un repositorio git de cualquier

gestor de repositorios como son GitHub www.github.com, GitLab www.gitlab.com,

BitBucker https://bitbucket.org/. Es decir, que el desarrollador con solo subir el

proyecto a cualquier gestor de los antes nombrados y vincularlo a App Manager podra

manejar las actualizaciones “en vivo”; testear la aplicacion con pruebas de ejecucion

paralelas; gestionar la ejecucion IC/DC.

CAPITULO 1. INTRODUCCION 5

• Auto generacion de los Pipelines de IC/DC al momento de conectar el repositorio del

usuario de la herramienta con la herramienta.

• Generar automaticamente el build de la aplicacion conectada.

Generar un instalador para la aplicacion compilada en el punto anterior. Al vincular la

aplicacion con la herramienta automaticamente se generara un instalador para esta. De

manera que con solo tocar un boton el usuario podra descargar el instalador y tener la

aplicacion funcionando en su maquina. De esta manera el desarrollador no se verıa obli-

gado a configurar uno externo, ahorrandole ası este proceso. El controlador de paquetes

(o instalador) se encargara de manejar los permisos de seguridad necesarios de los distin-

tos sistemas operativos, de preparar los paquetes y dejarlos listos para ser distribuidos.

Permitiendo la distribucion de la aplicacion a cualquier sistema operativo que se desee.

Con este instalador, al igual que con la aplicacion en si, se seguira la misma logica de

trabajo. Generando una abstraccion del instalador para dividir el funcionamiento comun

de un instalador, con el funcionamiento especifico que requiere cada instalador de cada

tipo de aplicacion soportada. De esta manera, para cada tipo de aplicacion soportada, se

generara un binario especifico. Por ejemplo, si App Manager soporta aplicaciones EUIJA

y aplicaciones Java, se tendra un binario de un instalador de aplicaciones EUIJA y un

binario de un instalador de aplicaciones Java, de esta manera se obtendran instaladores

bien compactos.

Mantener el instalador actualizado a la ultima version de la aplicacion en cuestion. Esto

es, cada vez que el desarrollador realiza cambios en la aplicacion, y por lo tanto actualize el

repositorio original de la aplicacion estos cambios se actualicen tambien en App Manager.

De esta manera cuando se haga uso del instalador este descargara la version actualizada

de la aplicacion y de esta manera siempre se estara utilizando la ultima version de esta.

A su vez, a quienes ya la tengan instalada la aplicacion con la simple accion de volver a

iniciar el instalador podran tener la version actualizada de la aplicacion.

Generar una instanciacion para un tipo de aplicacion diferente a las aplicaciones EUIJA

de todo el proceso antes desarrollado. Demostrando el funcionamiento de la herramienta

y como es el proceso, paso a paso, de anadir soporte para un nuevo tipo de aplicaciones.

1.3. Organizacion del trabajo

El contenido del presente trabajo se organiza en los capıtulos que pasan a describirse a conti-

nuacion.

En el Capıtulo 2 se presentan y describen las tecnologıas y herramientas utilizadas durante el

trabajo. Desde la herramienta principal que se va a modificar (App Manager), pasando por las

tecnologıas que esta herramienta utiliza como ası tambien las diferentes herramientas que posee

App Manager.

CAPITULO 1. INTRODUCCION 6

El Capıtulo 3 describe el enfoque adoptado durante esta tesis, pasando por DevOps y las maneras

de distribuir la aplicacion. Se dara un enfoque de como se deberıa hacer esto manualmente y los

problemas o dificultades que esto puede traer, evaluando ası el enfoque dado.

Por su parte, el Capıtulo 4 se focaliza en describir los aspectos correspondientes al diseno e

implementacion de la herramienta que materializa el enfoque expresado en el capitulo 3, se

presentan los principales componentes de la arquitectura y sus implementaciones las decisiones

que se tomaron para generar la abstraccion y tambien un desarrollo de como se instancio esta.

En tanto en el capıtulo 5 se desarrolla una comparacion entre el impacto que produce utilizar la

herramienta App Manager para la aplicacion de DevOps y para el despliegue de aplicaciones y

no hacerlo obteniendo diferentes resultados que quedaran expuestos.

Por ultimo, el Capıtulo 6 presenta las conclusiones finales del trabajo, las cuestiones a mejorar

tanto del enfoque como de su materializacion, y finalmente los cursos de accion para posibles

trabajos futuros.

Capıtulo 2Contexto

Una aplicacion no es solamente su codigo fuente, sino que la forma en que este codigo fuente es

empaquetado y provisto al usuario es de suma importancia para que la aplicacion sea funcional.

Se debe tener en cuenta todo el contexto que se genera alrededor de una aplicacion. Este tiene

que ser transmitido de forma clara de modo que el desarrollador pueda trabajar de forma efi-

ciente. Para dilucidar el contexto de una aplicacion se debe preguntar y poder responder ¿Cual

es el publico de mi aplicacion?, ¿Cuales son los requerimientos funcionales principales de la

aplicacion?, ¿Cuales los no funcionales? ¿Que tecnologıas se debera utilizar para satisfacer estos

requerimientos ? ¿Como se controlara el desarrollo de software para no desviarse de la vision de

los distintos interesados?, ¿Como se realizara la evaluacion tecnica de la aplicacion?, ¿Como la

comercial? ¿Como se va a distribuir la aplicacion?, entre otras. Todas estas preguntas son las

que uno debe hacerse antes y durante el ciclo de vida de la aplicacion va transcurriendo.

Toda aplicacion de software debe cumplir con su ciclo de vida correspondiente. En este ciclo de

vida se pueden identificar 6 etapas. (i) Planeamiento, (ii) Diseno del programa, (iii) Verificacion

y validacion, (iv) Codificacion de la aplicacion, (v) Despliegue, (vi) Retiro de la aplicacion.

Como seguir este proceso es algo difıcil y que tiene una complejidad importante, se desarrollo

una metodologıa de software centrada en la comunicacion entre equipos llamada Desarrollo y

Operaciones (DevOps).

DevOps corresponde un conjunto de tecnicas y herramientas que apoyan a la mejora del proceso

de desarrollo de software, que se apoya en la automatizacion y monitoreo de los procesos de

integracion de software. A la hora de poner en practica DevOps podemos definir cuatro principios

principales en este proceso:

1. Desarrollar y probar sistemas prematuramente.

2. Iterar sobre el desarrollo de la aplicacion.

3. Monitorear y validar software de calidad.

4. Generar ambientes de staging y produccion.

7

CAPITULO 2. CONTEXTO 8

En este capıtulo se describira en que consta cada parte y como se lleva a cabo. Tambien se

describen las tecnologıas que se utilizaran y en las que hace foco el trabajo, demostrando la

importancia de aplicar la cultura de DevOps en proyectos de software. Adicionalmente, se des-

criben herramientas previamente desarrolladas junto con una descripcion inicial de estas para

especificar el contexto del trabajo.

2.1. DevOps

El termino DevOps nace de la combinacion de las palabras desarrollo y operaciones. Este juego

de palabras ya sirve para dar una idea de la naturaleza del termino. Es una practica donde la

colaboracion entre diferentes disciplinas del desarrollo de software es alentada [21]. Este concepto

busca el trabajo en conjunto entre el equipo de desarrollo y el de operaciones [23]. DevOps surge

de la colision de dos conceptos muy utilizados hasta entonces como son las metodologıas (o

operaciones) agiles y la comprension del valor que tiene la comunicacion entre el equipo de

desarrollo y el de operaciones en el desarrollo de un producto de software [1]. Por metodologıas

agiles se entiende una metodologıa de desarrollo iterativo e incremental (pequenas mejoras, una

tras otra) basado en practicas tales como pruebas unitarias continuas, programacion por parejas,

frecuente interaccion con el cliente, correccion de errores, refactorizacion constante, etc.[7].

Antes de continuar con los principios de DevOps se definen tres conceptos basicos que seran

utilizados durante la explicacion de los mismos:

Contenedores: un contenedor es una unidad de software estandar que empaqueta el codigo

y todas sus dependencias para que la aplicacion se ejecute de manera rapida y confiable

de un entorno informatico a otros. Proporcionan una construccion a bajo nivel ya que

presentan una interfaz de un sistema operativo para el uso del desarrollador, pero no del

sistema operativo completo, sino que solo de las partes necesarias de un SO en ejecu-

cion [2]. Los contenedores aıslan el software de su entorno, por ejemplo, las diferencias

entre los entornos de desarrollo y de etapas, y ayudan a reducir los conflictos entre los

equipos que ejecutan software diferente en la misma infraestructura. Al hablar de contene-

dores tenemos que hablar tambien de Docker https://www.docker.com/. Es un proyecto

de codigo abierto que automatiza el despliegue de aplicaciones dentro de contenedores de

software, proporcionando una capa adicional de abstraccion y automatizacion de virtua-

lizacion a nivel de sistema operativo en Linux o Windows. Los contenedores Docker se

crean utilizando imagenes base. Una imagen de Docker puede incluir solo los requisitos

mınimos del sistema operativo para poder funcionar, o puede consistir en una sofisti-

cada pila de aplicaciones preconstruida lista para su lanzamiento generando un sistema

operativo mas completo y con mas funciones. Al construir imagenes con Docker, cada

accion tomada (es decir, comando ejecutado) forma una nueva capa en parte superior

de la anterior. Los comandos pueden ser ejecutados manual o automaticamente usando

Dockerfiles https://docs.docker.com/engine/reference/builder/ [2].

CAPITULO 2. CONTEXTO 9

Integracion Continua (IC): la IC esta basada en el trabajo colaborativo. Cada desarrollador

(o equipo de desarrollo) integra su trabajo con el de los demas en un codigo principal.

Esto es de gran valor en terminos de DevOps, ya que permite que diferentes grupos que

trabajen en simultaneo sobre el codigo de un mismo proyecto y puedan distribuir el codigo

de manera agil [16]. Los miembros del equipo deben integrar su trabajo frecuentemente

(normalmente a diario) generando multiples integraciones por dıa. Cada integracion de

codigo es verificada mediante un “build” automatico para detectar errores de integracion

lo mas rapido posible. En la practica esto se puede ver reflejado en el uso de funciones de

ramificacion y fusion que poseen los diferentes sistemas de control de versiones. Un sistema

de control de versiones es un software que al iniciarse monitorea los cambios de los archivos.

Por lo tanto, el desarrollador puede experimentar con nuevas ideas, modificando el codigo

de desarrollo, pero siempre tiene la opcion de volver a una version anterior especıfica del

codigo que utilizo para generar resultados particulares. Ademas, puede realizar comentarios

a medida que guarda cada version sucesiva para que quien revise el historial de desarrollo

del codigo pueda comprender la justificacion de las ediciones dadas. Tambien facilita la

colaboracion. Usando un VCS, quienes esten en el proyecto pueden hacer y guardar cambios

en el codigo, y quien supervise estos cambios puede incorporarlos automaticamente en la

base del codigo principal [3]. Git por su parte es un VCS mas utilizado en la actualidad, que

cuenta con implementaciones webtales como Github https://github.com/, Gitlab https:

//gitlab.com o Bitbucket https://bitbucket.org/ entre otras que proporcionan una

interfaz grafica agradable al usuario.

Distribucion Continua (DC): la distribucion continua es una practica de la ingenierıa de

software en el que los equipos producen software valioso en ciclos cortos y se aseguran de

que el software se pueda distribuir de manera confiable en cualquier momento [4]. Despues

de la automatizacion de la integracion de codigo y las testeos de unidad e integracion

realizados como parte de la IC, la distribucion continua automatiza la liberacion de ese

codigo testeado a los diferentes interesados (en adelante se utilizara el termino en ingles

stakeholders) del proyecto. Por eso, para que el proceso de distribucion sea eficaz, es

importante que la IC ya este incorporada a su canal de desarrollo. Los objetivos que se

obtienen al aplicar distribucion continua son [4]:

• Frecuencia de distribucion acotada: antes los lanzamientos de una aplicacion se da-

ban cada 6 meses aproximadamente. Aplicando distribucion continua, segun [4] en

promedio, una aplicacion se puede distribuir una vez por semana.

• Creacion correcta del producto esperado: la frecuencia con la que se distribuye el

producto, contribuye a que el equipo de desarrollo obtiene devoluciones de los sta-

keholders mas frecuentes, lo que permite al equipo corregir cosas y centrarse en las

tareas necesarias.

• Aumento de productividad y eficacia: se estima que un desarrollador pasaba un 20 %

del tiempo configurando y arreglando los ambientes de testeo, con la configuracion

CAPITULO 2. CONTEXTO 10

de la practica de DC esto quedo en el pasado ya que el pipeline de DC configura el

ambiente automaticamente.

• Lanzamientos confiables: el desarrollo de la aplicacion y los scripts se prueban repeti-

damente antes distribuir a produccion. Entonces, la mayorıa errores son descubiertos

en el proceso de implementacion. Con lanzamientos mas frecuentes, el el numero de

cambios de codigo disminuye en cada version. Esto hace que encontrar y solucionar

cualquier problema que surja sea mas facil, reduciendo el tiempo de impacto que

tienen estos errores.

• Aumento de la calidad del producto: la calidad ha aumentado notablemente, segun [4]

se sabe que el numero de errores con el que se lanzan las aplicaciones baja en un 90 %

utilizando la practica de DC. Esto se debe a que despues de la implementacion de

un cambio en el codigo, al realizar un commit, se testea el codigo por completo para

descartar que estos nuevos cambios generen errores en cadena en otras partes del

codigo pre existentes.

• Aumento de la satisfaccion del cliente: aplicar la practica de distribucion continua me-

jora la relacion con el cliente, se logra mayor confianza debido al continuo intercambio

que se genera.

2.1.1. Principios

Los principios que se deben seguir para aplicar DevOps a un proyecto son cuatro. Estos princi-

pios, junto con diferentes herramientas que suelen utilizarse para desarrollar DevOps como por

ejemplo Git https://git-scm.com/ para controlar las versiones del codigo fuente de un proyec-

to, Docker https://www.docker.com/ para automatizar la instalacion de aplicaciones dentro

de contenedores de software o Kubernetes https://kubernetes.io/es/ para desarrollar una

infraestructura multi-nube entre otras, son la base para aplicar este concepto. Se tiene que tener

en cuenta que el concepto de DevOps es un concepto que hace foco en como los desarrollado-

res pueden trabajar en equipo para producir un buen producto [8]. Si bien el concepto sigue

evolucionando, se basa en cuatro principios[16].

1. Desarrollar y probar sistemas prematuramente.

2. Iterar sobre el desarrollo de la aplicacion.

3. Monitorear y validar software de calidad.

4. Generar ambientes de staging y produccion.

Desarrollar y probar sistemas prematuramente, el objetivo de este principio se basa en permitirle

a los equipos de desarrollo desarrollar, hacer pruebas de manera prematura y ası observar como

se comporta la aplicacion antes de que este lista para ser desplegada. Cuando el equipo de

produccion comience su trabajo una vez se realice el primer commit, se van realizar pruebas

CAPITULO 2. CONTEXTO 11

de manera prematura para reconocer fallas de manera temprana y que ası, sea mas sencillo

resolverlas. El encargado de realizar las pruebas que dan como resultado un analisis a la calidad

del software, y la garantıa de que este funcione, es el equipo de produccion. Estas pruebas

se realizan una vez terminado el desarrollo de la aplicacion y esto es lo que DevOps busca

modificar, realizandose durante todo el proceso de desarrollo de la aplicacion. Desde el punto

de vista del equipo de produccion este cambio es muy beneficioso. Permite al equipo observar

prematuramente en el ciclo de vida de la aplicacion como el entorno se comportara cuando

soporte la aplicacion, detectar fallas futuras, inconsistencias del sistema y demas problemas que

puedan surgir.

Iterar sobre el desarrollo de la aplicacion, este principio esta basado en la automatizacion del

desarrollo de la aplicacion. Para concretar este punto no solo basta con usar diferentes herra-

mientas y practicas, sino que las personas a cargo de la aplicacion adopten la filosofıa de DevOps,

de lo contrario las practicas seran inutiles en la busqueda de la adopcion de DevOps [16]. El

foco de este principio se encuentra en la iteracion sobre la codificacion de la aplicacion. Se deben

anadir cada uno de los cambios desarrollados por los equipos de manera frecuente para que de

esta manera se pueda analizar el codigo y todos los equipos esten al tanto del avance de la apli-

cacion. Entre las practicas que se utilizan, se destaca la generacion de un pipeline de integracion

continua(IC) / distribucion continua (DC).

Monitorear y validar software de calidad, este principio tiene como concepto mover el monitoreo

de la aplicacion a una etapa mas temprana del ciclo de vida de esta, y no hacerlo solamente

y de manera aislada en la etapa de produccion. Esto se logra gracias a pruebas automatizadas

tempranas en el ciclo de vida (mientras se desarrolla y se testea la aplicacion) tanto para carac-

terısticas funcionales como no funcionales. Testear la aplicacion es la forma de asegurarse que lo

que se codifico se haga, y se haga sin errores. Los test de unidad, del ingles Unit Test, estan for-

mados por porciones de codigo que testean un fragmento particular de codigo [10]. Otro tipo de

test que deben verificar el codigo son los tests de integracion. A diferencia de los tests unitarios,

los tests de integracion se basan en testear las relaciones y las interfaces entre los modulos [11].

Los test nos permite garantizar que se cumplan las funcionalidades esperadas y las expectativas

de calidad, ayudando a encontrar esos errores o defectos que aun no se han descubierto. Busca

reducir el costo del desarrollo y desarrollar confianza en los clientes al evitar los molestos errores

de regresion.

Generar ambientes de staging y produccion es el ultimo principio del ambiente de testeo. El

desarrollador debe actualizar los nuevos lanzamientos en los servidores de staging, chequear que

todo funcione de manera correcta para despues realizar el lanzamiento de la aplicacion. Los

servidores de staging se convertiran en los nuevos servidores de produccion [21]. Este ultimo

paso, de generar el ambiente de staging, es el que va a permitir el lanzamiento de la aplicacion,

pero llegar a esto de manera optima no es sencillo. Una de las razones es que usualmente es

difıcil lograr un alto nivel de testeo automatizado de la aplicacion para tener confianza en que la

aplicacion no presentara fallas por lo que es necesaria la intervencion de un desarrollador para

finalizar el lanzamiento de la aplicacion [21].

CAPITULO 2. CONTEXTO 12

2.2. Herramienta de administracion de aplicaciones: App Ma-

nager

App Manager es una herramienta web que facilita a los equipos de desarrollo el desarrollo,

control y mantenimiento de sus aplicaciones. Es capaz de:

Generar el “build” de sus aplicaciones conectandolas con su respectivo repositorio Git.

Controlar por completo el ciclo de vida de una aplicacion.

Construir el pipeline IC/DC.

Testear aplicaciones automaticamente.

Distribuir aplicaciones mediante la creacion automatica de instaladores para todos los

sistemas operativos.

Notificar a usuarios finales instantaneamente de nueva version de una aplicacion en parti-

cular.

Monitorear la funcionalidad de las aplicaciones mediante estadısticas y reporte de errores.

App Manager tiene como principal objetivo la creacion y administracion de aplicaciones. Estas

aplicaciones pertenecen a organizaciones donde una organizacion puede estar formada por uno

o mas desarrolladores con acceso las aplicaciones de la organizacion. Cada usuario de una orga-

nizacion puede crear nuevas aplicaciones, vincularlas con el repositorio Git correspondiente a la

aplicacion y de esa manera conectar su aplicacion con App Manager. Una vez conectada la apli-

cacion con la herramienta se generara de manera automatica el pipeline IC/DC de la aplicacion,

al cual el usuario podra acceder. Tambien si la aplicacion realiza el build de manera exitosa,

se creara un instalador generado automaticamente por App Manager listo para ser descargado.

Tambien el usuario tendra acceso a diferentes tipos de analisis como puede ser reporte de errores

o analisis de estadısticas.

Al dıa de hoy App Manager solo permite trabajar en base a aplicaciones EUIJA (siglas de En-

riched UI Java Applications). Las aplicaciones EUIJA son aplicaciones desarrolladas utilizando

un SDK en particular. En un futuro, se espera que al menos cinco tipo diferentes de aplicaciones

deberıan poder ser conectadas.

2.2.1. Uso de App Manager

Para demostrar como se utiliza App Manager, a continuacion se explicara el ciclo completo desde

que se inicia sesion hasta que se obtiene un instalador de una aplicacion a partir de un ejemplo.

CAPITULO 2. CONTEXTO 13

Figura 2.1: Vista de registro de la plataforma.

1. Lo primero que se debe hacer es iniciar sesion en la plataforma. Como se puede ver en la

imagen 2.1 el usuario puede iniciarse tanto con su cuenta de google como de github https:

//github.com/ o facebook https://www.facebook.com/.

2. Una vez iniciado sesion debe crear una aplicacion en la plataforma. En la imagen 2.2 se

Figura 2.2: Vista de la plataforma correspondiente a la creacion de aplicaciones

puede observar que la organizacion “nicolas” esta queriendo crear una nueva aplicacion.

3. El tercer paso es cargar los datos de la nueva aplicacion. En el formulario que se observa

Figura 2.3: Vista del formulario a completar para crear una aplicacion.

en la imagen 2.3 se debe cargar el nombre de la aplicacion, la organizacion que lo crea, el

CAPITULO 2. CONTEXTO 14

tipo de aplicacion (esto es algo que esta en desarrollo para cuando se acepten diferentes

tipos de aplicaciones) y alguna descripcion de la misma.

4. El proximo paso es asociar la aplicacion con el repositorio correspondiente.

Figura 2.4: Vista de menu de una aplicacion

Figura 2.5: Vista de la carga del repositorio a la plataforma

5. Una vez cargada la aplicacion, automaticamente se crea el pipeline como se puede ver en

la imagen 2.6 y se puede observar si los tests realizados son aceptados o fallan y a partir

de esto descargar el instalador auto generado.

Figura 2.6: Vista del estado de la aplicacion en sus diferentes branchs

CAPITULO 2. CONTEXTO 15

2.3. Instaladores

Un instalador resume el proceso de desempaquetamiento de las piezas fundamentales para la

ejecucion de una aplicacion, a traves de una interfaz de usuario conveniente y auto suficiente.

Esta interfaz de usuario puede ser grafica o estar basada en texto que se genera en una lınea

de comandos como el shell de Unix (por ejemplo, bash). En el caso mas simple, una aplicacion

es simplemente un archivo ejecutable, y el sistema operativo sabe que hacer con el archivo para

ejecutarlo. El archivo de la aplicacion puede residir en una carpeta con subcarpetas y otros

archivos auxiliares, empaquetados en un solo archivo.

En la actualidad al crear un instalador para una aplicacion se debe tener en cuenta tanto para

que sistema operativo esta destinada la aplicacion, como tambien, en que sistema operativo se va

a desarrollar el instalador. Esto se debe a que no hay una unica manera de desarrollarlo. Esto se

puede hacer de diferentes maneras, desarrollandolo desde cero mediante codigo puro, utilizando

diferentes herramientas dependiendo el sistema operativo que estemos utilizando para desarro-

llarlo y el sistema operativo al que este destinada la aplicacion. Por eso es que a continuacion se

detallan algunos posibles casos.

2.3.1. Herramientas para generar un instalador en Windows

Para aplicaciones Windows existe un amplio abanico de herramientas a la hora generar de un

instalador para una aplicacion. Una de ellas es la extension que propone Visual Studio https:

//tinyurl.com/tjayue4c. Esta opcion es bastante sencilla, con una buena interaccion con el

usuario que va a crear el instalador que brinda la opcion de usar diferentes plantillas. Teniendo

en cuenta el tipo de instalador a crear, ya sea web, o un cd de instalacion por ejemplo. Una

vez que se eligio la plantilla adecuada, se deben agregar los archivos necesarios al instalador.

Para esto existe el “File System Editor” que controla que archivos son necesarios para distribuir

la aplicacion de manera correcta y donde se guardaran al momento de la instalacion https:

//tinyurl.com/tbj2erw2 . Tambien incluye el“File Types Editor”que se utiliza para establecer

asociaciones de archivos en la computadora de destino, asociando extensiones de archivo con su

aplicacion y especificando las acciones permitidas para cada tipo de archivo https://tinyurl.

com/exf2psxr. Otro de los editores que posee el instalador de Visual Studio es el “ Registry

Editor” que permite especificar claves y valores del registro que se agregaran al registro de

la computadora de destino https://tinyurl.com/26s3rtfr. Y algunos otros caracterısticas

menores que tambien permiten editar otro tipo de acciones que realizar el instalador.

Otra opcion que puede elegir el desarrollador, es Windows Installer Xml https://wixtoolset.

org/. Se trata de una herramienta de codigo abierto que le permite al usuario generar un

instalador para aplicaciones Windows. Esta herramienta permite configurar todo lo necesario

para que la experiencia del usuario instalando la aplicacion sea lo mas intuitiva. El desarrollador

debe codificar diferentes archivos para cumplir con todos los requerimientos del instalador. Por

cada tarea diferente que realiza debe crear un componente diferente con todos los archivos

CAPITULO 2. CONTEXTO 16

necesarios dentro. Debe agregar todos los archivos necesarios para que el programa funcione de

manera correcta, para esto, primero debe identificar cuales son estos archivos. Debe darle al

usuario diferentes opciones de instalacion, instalar el producto completo, solo instalar algunas

herramientas de este. Para esto debe crear caracterısticas. Una caracterıstica es un grupo de

componentes que el usuario puede decidir instalar todos de un principio o no, por ejemplo se

le puede dar la opcion al usuario de elegir donde instalar la carpeta de la aplicacion, o no. Se

le puede dar a elegir al usuario la opcion de tener un acceso directo en el escritorio, o no [14].

Es comun ver esto en los dialogos de instalacion como una lista de modulos llamada arbol de

caracterısticas.

2.3.2. Herramientas para generar un instalador en Linux

Linux es otro conocido Sistema operativo, el mas famoso al hablar de Software libre. Existen

tambien varias herramientas para generar instaladores para este sistema operativo. Un ejem-

plo es IzPack http://izpack.org/. IzPack no predefine una plantilla de instalacion rıgida.

Los instaladores generados por IzPack tambien proporcionan integracion nativa opcional, co-

mo crear accesos directos de escritorio, manipular un registro del sistema o cambiar a una

cuenta de administrador durante la instalacion. Para crear un instalador primero se hacer un

archivo xml en el que se indican que cosas se quieren que tenga el instalador y que cosas se

desean instalar. La etiqueta principal del fichero xml es <instalation> y debe llevar un atributo

con la version 1.0. Ahora hay que poner una serie de etiquetas mas o menos generales para

el instalador. Estas etiquetas indican idioma para el instalador, nombre de la aplicacion que

se va a instalar, version de la misma, tamano de la ventana del instalador, etc. Al ejecutar el

instalador saldra una ventana con una cierta informacion y botones de ”siguiente”, ası hasta

pasar por una serie de paneles con los se finaliza la instalacion. IzPack, ademas de permitir

definir paneles propios a medida, tiene una serie de paneles predefinidos habituales en los ins-

taladores https://izpack.atlassian.net/wiki/spaces/IZPACK/pages/491681/Panels. Por

ultimo queda definir que modulos se deben instalar (el ejecutable y la documentacion) y que

tiene cada uno de ellos. Esto se hace con la etiqueta <packs> y las sub etiquetas <pack>.

2.3.3. Herramientas para generar un instalador en MacOs

En cuanto al sistema operativo de Apple, MacOs https://www.apple.com/la/macos/what-is/

tambien existen herramientas para generar instaladores para aplicaciones de escritorio. Ası co-

mo para el sistema operativo Linux, se puede utilizar la version de IzPack para MacOs. Otra

alternativa es la herramienta propuesta por el propio Apple, llamada PackageMaker https:

//tinyurl.com/6jbvapy7. Hay dos tipos de paquetes de instalacion: paquetes de productos y

paquetes de componentes. Los paquetes de productos contienen la carga util de un producto

completo, ya sea como un solo componente o distribuido entre varios paquetes de componentes.

Los paquetes de componentes encierran un solo componente de un producto y generalmente es-

tan contenidos dentro de los paquetes de productos. Ademas, los paquetes de productos pueden

CAPITULO 2. CONTEXTO 17

referirse a paquetes de componentes externos a traves de referencias de paquetes. Para crear el

instalador el primer paso es crear una jerarquıa de archivos relativa que describa donde debe

instalarse cada archivo de la aplicacion. El proximo paso es ingresar toda la informacion del pa-

quete necesaria para la instalacion (titulo, version, descripcion, recursos, etc). Esta herramienta

tiene la posibilidad de generar un instalador sin tener que codificar nada. En caso que el usuario

desee agregar acciones o informacion adicional se puede hacer mediante lineas de comando.

2.3.4. AD-HOC

Ademas de las opciones antes mencionadas tambien existe la posibilidad de crear un instalador

completamente desde cero, sin utilizar ninguna herramienta como en las opciones menciona-

das anteriormente. Es decir, elegir un lenguaje que el equipo crea adecuado, generar el codigo

necesario para tener el instalador funcionando correctamente, reconocer los archivos necesarios

para poder distribuir la aplicacion a cualquier otro usuario de esta asegurando el correcto fun-

cionamiento. Todo esto, teniendo en cuenta que se debe brindar una interaccion con el usuario

optima. De esta manera el equipo encargado de el instalador deberıa codificar todo el codi-

go, pero tambien se asegurarıa que sea personalizado, que se pueda modificar y reutilizar para

futuras aplicaciones, que cumpla con cuestiones exigidas por el usuario que excedan a las ca-

racterısticas brindadas por las herramientas existentes. Tomando esta opcion el desarrollador

tambien se asegurarıa de elegir el lenguaje correcto para su instalador teniendo en cuenta el tipo

de instalacion a realizar. Podrıa tambien decidir cual va a ser la interaccion con el usuario de la

aplicacion, es decir, si pretende que este pueda tomar decision alguna sobre la instalacion o no.

Como por ejemplo si va a permitirle al usuario decidir donde instalar la carpeta de la aplicacion,

como llamarla, si desea o no un acceso directo en su escritorio o no, si desea elegir el idioma

de la aplicacion o no, si quiere aceptar actualizaciones automaticas o no, entre otras opciones

dependiendo el tipo de aplicacion que se este distribuyendo.

Al realizar un instalador ad-hoc se observan ciertas ventajas y desventajas. Una desventaja

que esta a la vista es el tiempo, es notorio que hacer un instalador ad-hoc implica un gasto

mayor de tiempo ya que al no usar ninguna plantilla se debe codificar todo desde cero. Otra

desventaja es que las herramientas generan una interfaz de usuario por defecto donde el usuario

solo debe seleccionar que cosas desea que sean visibles y cuales no, mientras que al hacer un

instalador ad-hoc la interfaz debe ser codificada en su totalidad. Por otro lado, realizar un

instalador de esta manera tiene sus ventajas. En la modernidad se puede observar que las nuevas

tecnologıas como son aplicaciones web o moviles (ya sean Android https://www.android.com/

intl/es_es/ o Ios https://www.apple.com/la/ios/ios-13/) presentan interfaces de usuario

sin interaccion activa con el usuario, ya que no debe realizar ninguna accion, solamente observa

como se va desarrollando la instalacion. Esto permite la instalacion a usuarios sin conocimiento

alguno. A comparacion de instaladores usuales que presentan una interaccion con el usuario

con multiples pasos que ademas, en usuarios sin conocimientos, generan confusion. Tambien

al no tener interaccion con los usuarios se tornan mas seguros ya que la instalacion queda

completamente a cargo del instalador.

CAPITULO 2. CONTEXTO 18

2.4. Conclusion

Con la integracion de la tecnologıa de DevOps al desarrollo de aplicaciones de escritorio la forma

de implementar y distribuir este tipo de aplicaciones cambio de manera drastica. Generando una

comunicacion mas fluida entre todos los equipos implicados en el desarrollo de las aplicaciones

y tambien con el cliente o usuario de estas. Tambien la automatizacion de los testeos unitarios

de la aplicacion o la automatizacion de la generacion del instalador tambien reduce el esfuerzo

requerido para configurar lanzamientos, haciendo posible que las organizaciones produzcan los

lanzamientos tan frecuentemente como se requiera. Se descubrio que los niveles mas altos de

automatizacion conducen a una garantıa de calidad mejorada. La lınea de produccion automa-

tizada de DevOps ayuda a garantizar que cada cambio se verifique antes de que se envıe para

la entrega. Porque cada el cambio en el codigo se verifica en cada etapa del desarrollo, y los

errores son descubiertos y resueltos sobre la marcha, los productos finales tienen menos errores

y el software puede ser lanzado facilmente [15].

Tambien se puede observar que tener una herramienta como App Manager, que ayuda al usuario

de esta a aplicar DevOps a su aplicacion desarrollando automaticamente un pipeline IC/DC

corriendo los tests desarrollados por el desarrollador generando instaladores automaticamente

es de gran valor para acortar los tiempos de desarrollo y despliegue de las aplicaciones. A su

vez, que sea unicamente aplicable a aplicaciones EUIJA es una limitante. Dado el potencial App

Manager, si se trabaja en que esta soporte cualquier tipo de aplicacion, seria de un potencial

aun mucho mas grande. La generacion de instaladores para las diferentes plataformas Windows,

MacOS y Linux y para diferentes tipos de aplicaciones es uno de los mayores desafıos tecnicos

que App Manager debe afrontar en pos de expandir su potencial. Es por eso que este trabajo

final de carrera se centrara en extender la funcionalidad tanto de la herramienta como de sus

diferentes partes (generacion del pipeline IC/DC, instalador automatico, etc) para diferentes

tipos de aplicaciones, desarrollando una abstraccion del proyecto de manera que dar soporte

para un nuevo tipo de aplicaciones deseado sea lo mas sencillo posible.

Capıtulo 3Enfoque

En el presente capıtulo se describen aspectos correspondientes al enfoque abordado para la

seleccion de las tecnologıas utilizadas para el trabajo final. Se presentaran las soluciones a las

falencias desarrolladas en el capıtulo anterior para el correcto despliegue de una aplicacion. Dicho

enfoque pretende dar solucion al problema central que se presenta en la actualidad cuando se

quiere desplegar una aplicacion de escritorio: la falta de conocimiento acerca de como desplegar

una aplicacion, y por consiguiente, los problemas que surgen a la hora de realizar tal fin. Para

esto se va a dar principal hincapie en la solucion parcial que se presenta en App Manager para

resolver este problema para aplicaciones EUIJA, demostrando su funcionalidad y la propuesta

que se desarrollara para aplicar esta solucion para diferentes tipos de aplicaciones y a partir de

esta poder pensar disenar y desarrollar una solucion.

Este capıtulo se divide en tres secciones que dan la pauta general del enfoque de esta tesis. La

primer seccion 3.1 describe las complicaciones o desafıos, tanto en la toma de decisiones como

en la implementacion, con las que se enfrentara cualquier desarrollador que elija llevar a cabo

el despliegue de su aplicacion sin ninguna herramienta que automatice este proceso. Es decir,

que debe realizar todo el proceso manualmente, tomando las decisiones necesarias para el buen

despliegue de su aplicacion. Se cuenta como, al aplicar DevOps a una aplicacion, existen ciertas

herramientas que se pueden utilizar para realizar esto de manera que sea util para todo tipo de

aplicaciones como subir su aplicacion a un repositorio git, la diferentes opciones para crear un

pipeline IC/DC con sus diferentes pasos y como distribuir la aplicacion. Pero por sobre todo

presenta las complicaciones mas grandes que tendra que resolver el desarrollador para poder

lograr el despliegue de su aplicacion de manera exitosa. Luego, la segunda seccion 3.2, describe

como se puede automatizar el proceso explicado en la seccion anterior mediante una herramienta.

Se analizara la adopcion de App Manager para mejorar el proceso de adopcion de DevOps, ya

que el proposito que tiene esta plataforma es automatizar el flujo de trabajo de una aplicacion

EUIJA aplicando DevOps. Tambien se describe cual es el ciclo que se debe seguir para generar la

adopcion a DevOps desde la herramienta desde el primer paso que es conectar la aplicacion con

la herramienta hasta el ultimo que es descargar el instalador auto generado. Por ultimo, en la

19

CAPITULO 3. ENFOQUE 20

seccion 3.3 se describe el objetivo de esta tesis, que es lo que se pretende realizar en este trabajo

utilizando la herramienta App Manager para desarrollar una herramienta capaz de automatizar

el despliegue de cualquier tipo de aplicaciones.

3.1. Problematicas para el despliegue de aplicaciones de escri-

torio

Previo a la implementacion de la herramienta, se siguio paso a paso el ciclo de vida de una

aplicacion de escritorio para identificar los inconvenientes a la hora de realizar el despliegue

de la misma. Se utilizo una aplicacion WPF para poder evidenciar mejor los problemas y

los resultados a brindar ya que, a pesar que los diferentes tipos de aplicaciones tengan cada

uno sus caracterısticas propias, el proceso sera equivalente en muchos aspectos y tomando a

este tipo de aplicaciones como puntapie inicial se podra reconocer la problematica general a

solucionar. Windows Presentation Foundation https://docs.microsoft.com/en-us/dotnet/

framework/wpf/getting-started/(WPF) es un sistema presentado por Microsoft ttps://

www.microsoft.com/ para crear aplicaciones de interfaces de interaccion. La plataforma que

desarrollo WPF admite un amplio conjunto de caracterısticas de desarrollo de aplicaciones que

incluyen un modelo de aplicacion, recursos, controles, graficos, diseno, enlace de datos, docu-

mentos y seguridad. Es un subconjunto de .NET Framework https://dotnet.microsoft.com/

download/dotnet-framework/net472. WPF utiliza el Lenguaje de marcado de aplicacion ex-

tensible (XAML) https://docs.microsoft.com/en-us/dotnet/desktop-wpf/fundamentals/

xaml para proporcionar un modelo declarativo para la programacion de aplicaciones. Una vez

desarrollada una simple aplicacion WPF, compuesta por una ventana con botones y campos a

llenar para lograr una interaccion con el usuario, se inicio el proceso de despliegue de la misma.

En la figura 3.1 se puede observar la aplicacion WPF desarrollada para realizar las pruebas

necesarias que se necesitaron para evaluar las diferentes situaciones que seran desarrolladas mas

adelante. Esta aplicacion fue necesaria para poder realizar pruebas e ir conociendo, mediante la

practica, el proceso que se querıa estudiar. Gracias a esto, se llego a diferentes conclusiones que

se desarrollaran a continuacion.

El despliegue de aplicaciones, sea cual esa el tipo de esta es un proceso que tiene sus complica-

ciones y problematicas. Como se explico en la seccion 2.1 aplicar el concepto de DevOps a una

aplicacion necesita de una configuracion particular. Desde cargar la aplicacion a un repositorio

hasta generar los pipelines de IC/DC para poder testear la aplicacion automaticamente. Esta

tarea puede resultar engorrosa si quien la realiza no tiene los conocimientos basicos sobre el tema

o si es nuevo en aplicando DevOps, pero dentro de la complejidad que se necesita para realizar

el despliegue por completo de una aplicacion, no es una tarea que requiera de demasiado tiempo

para ponerla en funcionamiento.

Por otro lado para poder completar el ciclo de distribucion de una aplicacion se debe generar el

instalador de la misma. Este proceso presenta una complejidad importante y que puede traerle

CAPITULO 3. ENFOQUE 21

Figura 3.1: Aplicacion WPF desarrollada para realizar la pruebas.

complicaciones al desarrollador que se explicaran en la seccion siguiente.

3.1.1. Crear y mantener pipeline IC/DC

La manera de configurar el pipeline IC/CD puede variar ya que hay diferentes maneras de

hacerlo. Hay muchas herramientas que se pueden utilizar para esto, probablemente la mas co-

nocida sea Jenkins https://www.jenkins.io/ pero tambien hay otras opciones como Apa-

che Gump https://gump.apache.org/, CruiseControl http://cruisecontrol.sourceforge.

net/ o Travis CI https://travis-ci.org/ entre otras. Otra opcion por la que se puede optar,

es hacerlo mediante Gitlab CI https://docs.gitlab.com/ee/ci/. Este gestor de repositorios

tiene la opciones de configurar un pipeline IC/DC mediante un archivo Yalm que debe ser ana-

dido en el proyecto. Este archivo por defecto debe llamarse “.gitlab-ci.yml” aunque se pueden

realizar configuraciones en Gitlab para que el archivo pueda llamarse de otra manera deseada.

Este archivo se encarga de definir la estructura y el orden de ejecucion de las tareas del pipeline.

Ademas se debe configurar que acciones realizar en caso de que se produzcan condiciones especı-

ficas como por ejemplo el caso de que una etapa falle o no. El motor que hace que la ejecucion de

este pipeline sea posible es Gitlab Runner https://docs.gitlab.com/runner/. Gitlab runner

es el proyecto de codigo abierto que se usa para correr cada uno de los trabajos a realizar en

cada etapa del pipeline y enviar los resultados de vuelta a Gitlab. Fue disenado para correr en

GNU/Linux, MacOs y Windows. Su instalacion se puede hacer mediante Docker o directamente

en el SO del usuario.

Para la configuracion de este archivo, lo primero que se debe hacer es elegir la imagen que se

usara. Las imagenes de Gitlab son imagenes monolıticas que corren todos los servicios necesarios

CAPITULO 3. ENFOQUE 22

en un contenedor solo https://docs.gitlab.com/omnibus/docker/#gitlab-docker-images.

Luego de esto un se dividira el pipeline dos partes.

BUILD: mediante scripts se crea el build de la aplicacion. En el caso de una aplicacion WPF

por ejemplo se puede hacer el build indicando la ruta del proyecto. En este caso ademas

se crea un artefacto para almacenar ese build y poder, por ejemplo, descargarlo o subirlo

a la nube, como puede ser mediante DigitalOcean https://www.digitalocean.com/ que

nos permite realizar este tipo acciones.

DEPLOY: este trabajo se encarga de la distribucion de las aplicacion. Una forma de hacerlo

es usando la herramienta dpl https://github.com/travis-ci/dpl que fue desarrollada

para CI en Gitlab.

Suponiendo este caso, donde las etapas fueron estas dos (build y deploy), la ejecucion es la

siguiente:

1. Todos los trabajos del build son ejecutados en paralelo.

2. Si los trabajos del build fueron exitosos, se ejecutan los trabajos de la etapa deploy en

paralelo.

3. Si todos los trabajos de la etapa deploy fueron exitosos, el commit es marcado como

“exitoso”.

4. Si alguna de las etapas anteriores falla, el commit es marcado como “defectuoso” y ningun

trabajo o etapa siguiente es ejecutada.

3.1.2. Distribuir la aplicacion

Para distribuir su aplicacion de escritorio, el desarrollador tiene en la actualidad dos opciones

a tomar. Por un lado el desarrollador puede crear un instalador propio desde cero, implemen-

tandolo por completo, seleccionando tecnologıas, disenando una interfaz de usuario, tomando

decisiones en cuanto a la interaccion del usuario con la herramienta. Otra opcion puede ser

utilizar diferentes herramientas desarrolladas para ayudar en la creacion de instaladores en las

que no debe preocuparse mayormente por estas decisiones de diseno e implementacion. Pero

para distribuir la aplicacion de manera correcta no alcanza solo con crear un instalador para

la aplicacion en cuestion. Hay otros puntos que se deben abordar para un correcto despliegue

de esta. Por ejemplo tambien se debe presentar un nuevo instalador para cada nueva version

que salga de la aplicacion del usuario cada vez que este la modifique. Esta tarea puede ser muy

engorrosa si cada vez que se generan actualizaciones, ya sea por correcciones de errores o por

nuevas herramientas que presente el usuario, el desarrollador de la aplicacion debe crear un nuevo

instalador por completo. Se debe tener en cuenta que es muy comun que las primeras versiones

de las aplicaciones, por mas de que hayan sido testeadas, suelen presentar fallas. Pensemos que

CAPITULO 3. ENFOQUE 23

es demasiado costoso testear absolutamente todos los casos de uso teniendo en cuenta que todos

los errores ademas se pueden generar en entornos especıficos.

A la hora de desarrollar un instalador, si la decision es la de crearlo desde cero hay que tener

en cuenta ciertas cosas. Por empezar se tiene que entender el concepto de instalador. Como

se dijo anteriormente un instalador resume el proceso de desempaquetamiento de las piezas

fundamentales para la ejecucion de una aplicacion en una terminal a traves de una interfaz de

usuario conveniente y auto suficiente. Para desarrollar un instalador lo primero que se debe

decidir es el entorno sobre el que se va a crear este instalador. En ocasiones llega a ser necesario

que el desarrollador aprenda un lenguaje de dominio especifico (LDS) nuevo para desarrollar

este instalador. Un LDS no es mas que un lenguaje definido especıficamente para resolver los

problemas de un dominio concreto[9]. Para elegirlo es importante tener en cuenta el tipo de

instalador a crear, si va a ser web, de escritorio o movil, como va a ser su interfaz, la interaccion

con el usuario, como se va a distribuir, quienes seran los usuarios de la aplicacion ya que se

debe tener en cuenta sus conocimientos a la hora de realizar una instalacion, que metodos de

seguridad debera cumplir la aplicacion en el entorno en el que sera instalada ya que todo esto

definira cual sera el mejor LDS. Como se dijo antes, un instalador empaqueta una aplicacion,

pero no todos los archivos que se crean al realizar un build de una aplicacion son necesarios para

distribuirla. Por eso tambien se debe identificar cuales son los archivos necesarios para poder

distribuir la aplicacion, ya que incluir archivos innecesarios en la instalacion lo unico que genera

es crear un instalador mas grande, mas pesado y por lo tanto menos compacto. Con los archivos

identificados y el lenguaje decidido se empieza el desarrollo del instalador. Un instalador, sea el

instalador que sea, tiene ciertas funciones basicas y comunes a todos los instaladores sea cual

sea su entorno y la aplicacion a instalar:

Se debe crear un directorio. En este directorio se almacenaran todos los archivos necesarios

para correr la aplicacion. Aquı es donde el instalador desempaqueta todo y deja todo listo

para la ejecucion de la aplicacion. A su vez este puede ser el lugar donde la aplicacion guarde

informacion necesaria que se va generando a medida que se va utilizando la aplicacion como

puede ser por ejemplo el guardado de datos relevantes para el usuario generados por la

aplicacion.

Se deben agregar al instalador los binarios necesarios para la instalacion y ejecucion de

la aplicacion en la terminal del usuario. Se debe dar soporte para diferentes sistemas

operativos teniendo en cuenta que no se sabe el sistema operativo en el que el usuario

desee utilizar la aplicacion. Dependiendo de esto ultimo se deben respetar, en cada caso,

las normas que establece cada sistema operativo.

Se debe crear un interfaz. Esta interfaz de usuario debe estar orientada y pensada para

cualquier tipo de usuario que pueda llegar a utilizar la aplicacion. Desde un usuario que no

tenga ningun tipo de conocimiento acerca de computacion hasta de un experto. Es por esto

que la interaccion con el usuario debe ser clara y concisa. En muchos casos un instalador

permite elegir entre dos tipos de instalacion, basica y avanzada. En la instalacion basica

CAPITULO 3. ENFOQUE 24

el instalador automatiza todo el proceso y solo le informa al usuario de las tareas que va

realizando (creacion de directorios, descarga de archivos necesarios, creacion de accesos

directos) el usuario solo debe esperar que termine la instalacion sin interactuar. Por otro

lado en la instalacion avanzada el usuario suele elegir donde crear ese directorio, si desea

crear o no un acceso directo si le permite al instalador descargar ciertos archivos y demas

acciones dependiendo especıficamente de cada instalador.

Se debe crear un desinstalador. Ası como se desarrolla el instalador, se debe permitir al

usuario, una vez instalada la aplicacion, desinstalarla. Este desinstalador debe eliminar

todo archivo que se haya instalado y/o creado con la instalacion de la aplicacion, como

tambien a partir de su uso. Debe eliminar todo rastro de la aplicacion del entorno del

usuario como si esa aplicacion nunca hubiese estado en ese terminal.

Por otro lado, se puede tomar la decision de crear el instalador de la aplicacion a partir

de herramientas que existen para este fin. Esta solucion tiene sus ventajas y sus desven-

tajas. Crear un instalador a partir de una herramienta le permite al desarrollador generar

un instalador sin necesidad de codificarlo desde cero. Esto es una ventaja en terminos

de tiempo ya que es mas rapido pero tambien en terminos de aprendizaje. Es mas facil

aprender a utilizar una herramienta que esta disenada para ese fin, con tutoriales, con

ejemplos, que aprender un nuevo LDS desde cero para desarrollar un instalador. Esta es

una de las mayores ventajas que se observa, ya que se ahorra algo tan valioso como es el

tiempo. Ademas no es necesario testear el codigo de este instalador ya que ya esta testeado

por los creadores de las herramientas. Con seguir los pasos explicados en cada uno de sus

manuales o sus tutoriales es suficiente. A su vez presenta sus desventajas el uso de este

tipo de herramientas para generar el instalador. Las interfaces que ofrecen las herramien-

tas suelen ser anticuadas, con pocas caracterısticas a configurar, sobre todo en lo que es

interfaz de usuario. La realidad es que estas interfaces al lado de interfaces web o moviles

quedaron muy atras. Visualmente no son atractivas y, mediante herramientas como estas,

es imposible renderizar una interfaz de usuario web para el instalador de una aplicacion

ya que la interfaz es unica para todos los instaladores que se creen con dicha herramien-

ta. Ademas suelen necesitar de una intervencion activa del usuario seleccionando donde

instalar los archivos, si desea instalarlos todos o solo una parte cosa que, para usuarios

con conocimientos basicos, siempre es un problema. Hoy por hoy se puede observar, por

ejemplo en aplicaciones moviles, que la interaccion del usuario a la hora de la instalacion

es mınima. Lo unico que debe hacer es aceptar el inicio de la instalacion y en algunos casos

especıficos aceptar ciertos terminos y licencias. De todo lo demas se encarga el instalador

de manera “invisible”. Otra desventaja que pueden llegar a tener este tipo de herramientas

es que no todas son gratuitas, sino que se debe pagar una suscripcion o un monto fijo para

su descarga y utilizacion. Este tipo de instaladores, a diferencia de los instaladores creados

desde cero suelen ser mucho mas pesados ya que tienen logica de la herramienta que se

puede evitar si se utiliza el otro metodo de creacion. Otro punto en contra que les podemos

asociar a este tipo de instaladores es que pueden requerir que el usuario que vaya a instalar

CAPITULO 3. ENFOQUE 25

la aplicacion necesite instalar software previo para poder correr el instalador ya que utiliza

tecnologıas, mediante la herramienta, que debe tener el usuario en su computadora para

poder llevar a cabo la instalacion.

Como se explico al principio de esta seccion, a la hora de hablar de la distribucion de herra-

mientas se debe hablar tanto de los instaladores para las aplicaciones como tambien del manejo

de las actualizaciones de las mismas. Este punto es de vital importancia a la hora de pensar

en el despliegue de aplicaciones ya que mantener al usuario de la aplicacion actualizado es fun-

damental. Esto se debe a que con estas actualizaciones se solucionan errores reportados por

los usuarios de las aplicaciones, se agregan herramientas a la aplicacion que surgieron porque

usuarios pidieron ese soporte, se presentan actualizaciones por modificaciones necesarias en la

aplicacion, se anade soporte para nuevas tecnologıas, etc. Si al disenar el instalador no se piensa

en esto es muy probable que a futuro sea un problema. Si no se desarrolla una solucion para que

los instaladores permitan que al agregar o generar un cambio al software desarrollado, por mas

sencillo que sea, se pueda modificar el instalador para aplicar estas actualizaciones y ası poder

redistribuir el instalador de nuevo, significa que cada vez que se genere una nueva version de

la aplicacion desarrollada se tenga que crear y distribuir un nuevo instalador. Cosa que como

se explico en esta misma seccion no es para nada sencilla. Seria totalmente engorroso tener que

realizar esto. Es inevitable pensar que, por mas que la aplicacion este testeada, se hayan testeado

absolutamente todos los posibles casos de uso que existen. Es por esto que siempre al lanzar una

aplicacion al mercado se deben corregir y atacar cambios que los usuarios de las aplicaciones

reportan por mas mınimos que sean. Tener que desarrollar un nuevo instalador por cada vez que

esto pase serıa un trabajo mucho mas ineficaz que si solo hubiese que adaptar el instalador ya

creado. Y por mas que el instalador estuviese disenado de manera que aplicar los cambios para

generar un nuevo instalador fuese sencillo, esto tambien sigue siendo un trabajo engorroso por

la cantidad de cambios que se pueden llegar a realizar.

Una vez desarrollado el instalador, el trabajo no termina ahı, ya que luego de generar el ins-

talador el desarrollador debe distribuirlo. Este es otro conflicto con el que se puede encontrar

el desarrollador ya que habıa diferentes opciones para hacerlo, todas son validas y todas tienen

sus pros y sus contras. Entre las mas comunes podemos encontrar que la aplicacion se puede

distribuir mediante los conocidos mercados de aplicaciones. Existen los que representan a un

sistema operativo en particular, existen otras alojadas en la nube que le cobran al usuario por

subir su aplicacion o bien se puede crear un mercados de aplicaciones para la empresa que realizo

la aplicacion donde subira todos sus desarrollos. Otra opcion muy utilizada es la de crear una

pagina web disenada para distribuir la aplicacion, donde se obtenga informacion de la aplicacion,

tutoriales, foros, etc y obviamente el instalador de la misma.

3.2. DevOps por App Manager

Como se explico en el capitulo anterior App Manager es una herramienta web creada para

automatizar el despliegue de aplicaciones EUIJA. El objetivo principal de esta herramienta es

CAPITULO 3. ENFOQUE 26

facilitar al desarrollador el proceso de despliegue de su aplicacion siguiendo los pasos necesa-

rios explicados en la subseccion 2.2.1. Conectar una aplicacion con la herramienta para luego

automaticamente generar el pipeline IC/DC, a su vez mostrar la historia de los builds de las

aplicaciones y tambien auto generar los instaladores de dichas aplicaciones.

Teniendo en cuenta el proceso explicado en la seccion anterior, se puede analizar que aplicar

DevOps a una aplicacion es algo util y que tendra sus beneficios a la hora de desarrollar y

desplegar la aplicacion. Pero tambien tiene sus complicaciones se elija el camino que se elija

para aplicar DevOps. Ya sea configurar el pipeline mediante Gitlab o hacerlo de otra manera;

elegir el gestor para subir la aplicacion en cuestion; decidir si utilizar una herramienta para crear

el instalador o no y sea cual sea la decision crear el instalador; que metodo de distribucion del

instalador se utilizara. Todo esto implica tiempo, para tomar las decisiones y llevarlas a cabo

y tambien conocimiento o aprendizaje por lo explicado anteriormente. Por estas razones es que

App Manager es una buena opcion para aplicar DevOps si se esta desarrollando una aplicacion

EUIJA. Esta herramienta busca, automatizando todo este proceso, que el desarrollador solo se

vea avocado a desarrollar su aplicacion mientras que de todo lo demas se encarga la herramienta.

3.2.1. Crear y mantener pipeline IC/DC

Este paso es una de las grandes optimizaciones que ofrece App Manager. Como se explico an-

teriormente el pipeline de IC/DC es una parte fundamental en la adopcion de DevOps a un

proyecto. Con este se controla el flujo de desarrollo de la aplicacion, se chequea que no se gene-

ren problemas de actualizaciones en el codigo, es decir, que si hay dos equipos o desarrolladores

trabajando sobre el mismo codigo unos no borren el codigo de los otros. App Manager, auto-

matiza la creacion de este pipeline para que el desarrollador no tenga que hacerlo, ahorrandole

tiempo de codificacion del mismo y el aprendizaje necesario que se necesita para crear el pipe-

line. Cuando un usuario vincula su aplicacion cargada a un repositorio de un gestor con App

Manager el pipeline se crea automaticamente.

Figura 3.2: Diferentes ramas del repositorio y su estado.

En la figura 3.2 se puede observar desde el menu de una aplicacion las diferentes ramas de

trabajo que posee el pipeline. La primera llamada master es la general y donde se almacena

el proyecto final. En esta podemos observar el estado de ese pipeline y cuando fue actualizado

por ultima vez. Ası como quien realizo estos ultimos cambios con un link al repositorio donde

podemos observar estos cambios en profundidad. Cada vez que se actualiza el pipeline, este

vuelve a trabajar y realiza las acciones que tiene implementadas . Si el estado del pipeline es

CAPITULO 3. ENFOQUE 27

satisfactorio se permite la opcion de descargar un instalador de la aplicacion, de lo contrario esta

opcion no es posible. Todo este proceso es automatico por lo que el usuario no debe generar el

pipeline porque este se crea automaticamente al cargar su proyecto a App Manager.

3.2.2. Distribuir aplicacion

Como se explico en la seccion 3.1.2, la distribucion de la aplicacion es una parte esencial en el

proceso de despliegue de una aplicacion. Tambien se demostro que existe mas de una posibilidad

a la hora de llevar a cabo esto y que toda solucion tiene su costo/beneficio. App Manager tambien

tiene su solucion a este paso del proceso ya que como se explico brevemente en la seccion anterior,

App Manager, si el pipeline CI/CD se construye y pasa todas sus etapas satisfactoriamente,

crea un instalador automaticamente. Este instalador se puede descargar a la computadora del

usuario simplemente haciendo clic en el boton y con esto el usuario ya tiene el instalador en su

computadora. El instalador que se descarga es un instalador con una interfaz de usuario moderna,

donde el usuario tiene interaccion pasiva con el mismo. Solo debe ejecutar el instalador y este

realiza todas las acciones por si solo, no debe seleccionar ni indicar nada el usuario. Se ira

informando por la interfaz de usuario todos los pasos que se van ejecutando de la aplicacion y

si surge algun problema. Una vez finalizada la ejecucion del instalador e instalada la aplicacion

el instalador dara la opcion al usuario de cerrar este instalador o de iniciar la aplicacion para

comenzar con el uso de la misma. Tendra la opcion de descargarlo para los sistemas operativos

Windows https://www.microsoft.com/es-ar/windows, MacOs https://www.apple.com/la/

macos/what-is/ o Linux https://www.linux.org/. Cada vez que se genere una actualizacion

del repositorio original del del usuario, estos cambios se veran reflejados en App Manager, de

esta manera el pipeline IC/DC volvera a ejecutarse corriendo todos los trabajos que tiene para

ejecutar. De esta manera, si el pipeline termina todos sus trabajos de manera satisfactoria se

actualizara el link para la descarga del instalador auto generado obteniendo ası la nueva version

del mismo. Con estas medidas se logra que no se tenga que desarrollar un nuevo instalador por

cada vez que se actualice el codigo fuente. Junto con este instalador se anade un enlace a una

pagina web, tambien generada automaticamente, que podra ser utilizada por el desarrollador

para distribuir la aplicacion en cuestion. Esta web es muy sencilla y posee los datos de la

organizacion que la creo, informacion sobre la aplicacion (esta informacion se obtiene de la

descripcion realizada cuando se creo la aplicacion) y el instalador de la misma para los diferentes

sistemas operativos.

3.3. Abstraer App Manager

Por lo que se explico hasta el momento podemos decir que aplicar DevOps al desarrollo y

despliegue de una aplicacion es muy beneficioso pero muy costoso a la vez. Es por esto que

la existencia de una aplicacion como App Manager que permita, simplemente conectando el

repositorio de la aplicacion del usuario a App Manager, generar el pipeline IC/DC y obtener

CAPITULO 3. ENFOQUE 28

automaticamente un instalador de la aplicacion, entre otras cosas, es de gran ayuda para el

desarrollador. Analizando el potencial que tiene esta herramienta, por lo beneficioso que es

aplicar DevOps al proceso de creacion de software y las complicaciones que se pueden presentar

para hacerlo de manera correcta manualmente, se analizo la posibilidad de extender esta solucion

a cualquier tipo de aplicacion para darle a App Manager aun mas valor. Teniendo en cuenta

que la plataforma ya esta implementada y que la solucion para aplicaciones EUIJA funciona,

se creyo que esto podıa servir para cualquier tipo de aplicaciones. Utilizando el codigo que ya

existe, reconociendo las partes comunes y generando una abstraccion comun para todo tipo de

aplicaciones y que todas convivan en la misma plataforma de App Manager. Teniendo en cuenta

que las aplicaciones EUIJA no son ni las mas conocidas ni las mas utilizadas pero reconociendo

el poder que tiene la herramienta App Manager y el impacto que puede generar que se extienda

la funcionalidad de la misma para diferentes tipos de aplicaciones fue que se tomo la decision de

extender su funcionalidad.

Generar una abstraccion del codigo sin antes conocer en profundidad como era el ciclo que debıa

atravesar una aplicacion para que sea soportada por App Manager podıa ser un fracaso, ya que

el codigo presenta una complejidad importante a la hora de entenderlo como para generar esta

abstraccion. Por esta razon, fue que se tomo la decision de primero, para entender bien como

funciona App Manager, seguir el ciclo completo por el que pasa una aplicacion en App Manager.

Lo primero que se penso fue generar una especie de instanciacion que servirıa de ejemplo para

luego si generar la abstraccion final. Para esto se eligio otro tipo de aplicaciones diferente a las

aplicaciones EUIJA para poder identificar mas facilmente las partes comunes entre ambos casos

y generar, en base al ejemplo de estos dos tipos de aplicaciones (las aplicaciones EUIJA y el

nuevo tipo que se eligio para el estudio) una abstraccion. Se pudo generar una abstraccion que

realmente sea funcional para cualquier tipo de aplicacion que se quisiese agregar a la plataforma.

Figura 3.3: Evolucion esperada de App Manager.

Como se puede ver en la figura 3.3, para este nuevo caso de uso se eligieron las aplicaciones

Windows Presentantion Foundation (de ahora en mas WPF) para agregar a la plataforma App

Manager. Se eligio este tipo de aplicaciones ya que representan aplicaciones de escritorio, que es

a uno de los tipos de aplicaciones a los que apunta App Manager. Este lenguaje esta basado en

XAML, tecnologıa muy utilizada por los desarrolladores y pueden escribirse tanto en c# https:

CAPITULO 3. ENFOQUE 29

//docs.microsoft.com/en-us/dotnet/csharp/ como en .NET https://dotnet.microsoft.

com/. Tambien se eligio porque WPF tiene caracterısticas muy potentes de creacion de plantillas,

estilo y enlace que se adaptan a grandes aplicaciones. Funciona en cualquier sistema operativo

Windows, el sistema operativo mas usado en el mundo y cuyos usuarios son de todo tipo. Lo

que se realizara sera, en primera medida, realizar el ciclo de despliegue de una aplicacion WPF

sin utilizar App Manager. Desarrollar la aplicacion , generar un pipeline IC/DC y desarrollar

un instalador mediante una herramienta disenada para esto. Con esto se busca mostrar luego la

diferencia entre este proceso utilizando App Manager y sin utilizarlo con una que sea desarrollada

completamente desde cero. De esta manera podremos demostrar y presentar que tan complejo

resulto este proceso para mostrar tambien las mejoras que se obtienen al utilizar App Manager.

Una vez hecho esto y teniendo identificado todo el proceso para aplicar DevOps a una aplicacion

WPF, se pasara a estudiar como esta desarrollado App Manager y se identificaran las partes

comunes entre la aplicacion de DevOps para aplicaciones EUIJA con respecto a la adopcion de

DevOps a aplicaciones WPF. Luego utilizando la solucion Implementada en App Manager, se

agregara el caso de uso de las aplicaciones WPF a la misma analizando la re utilizacion de codigo

posible para la futura abstraccion que se desea obtener. De esta manera App Manager pasara a

ser una herramienta lista para la automatizacion del proceso de DevOps a aplicaciones no solo

EUIJA, ya que se debera tener en cuenta que parte del proceso es diferente para los diferentes

tipos de aplicaciones y cual es igual para desarrollarlo y que ası, aplicaciones de diferentes tipos

sean aceptadas por la herramienta.

3.4. Conclusion

Aplicar DevOps al desarrollo de una aplicacion, de hacerse de la manera correcta y con los

conocimientos necesarios, es una tecnologıa que va a mejorar el proceso de desarrollo y despliegue

de una aplicacion de gran manera. Sin embargo aplicar DevOps y utilizarlo de la manera correcta

no es sencillo. Es un proceso costoso para aplicar teniendo en cuenta que se deben agregar muchos

conceptos. Ademas estos conceptos se deben ensenar y aprender, y a pesar de ser fundamentales

para aplicar DevOps, no son necesarios para el desarrollo y despliegue de la aplicacion, pudiendo

desplegarla sin aplicar DevOps. Es por esto que automatizar, en la medida de lo posible, este

proceso es algo que vale mucho, ya que le da al desarrollador (o equipos de desarrollo) el valor

de poder aplicar una tecnologıa que realmente vale la pena sin tener que interiorizarse en los

conocimientos de como implementar y utilizar estos conceptos. Es por eso que App Manager es

tan valiosa y tiene un gran potencial que debe ser aprovechado por los desarrolladores. El hecho

de que este orientada solo a aplicaciones EUIJA es una traba en el camino de la utilizacion

de la herramienta ya que el proceso es el mismo para cualquier tipo de aplicacion. Por esto es

que se quiere extender esta solucion a diferentes tipos de aplicaciones abstrayendo el desarrollo

en comun para los diferentes tipos de aplicaciones y lograr convertir a App Manager en una

herramienta que sea funcional para diferentes tipos de aplicaciones.

Capıtulo 4Diseno e implementacion

En el presente capıtulo se detallan aspectos correspondientes al diseno e implementacion del

framework desarrollado para extender la herramienta App Manager para todo tipo de aplica-

ciones, materializando el enfoque descripto en el capıtulo anterior. En la Seccion 4.1 se describe

en detalle como, a partir del proyecto original, se modifico el proyecto para generar uno nuevo.

Permitiendo anadir soporte para diferentes tipos de aplicaciones de manera clara y sencilla. Esta

seccion, a su vez, esta dividida en dos grandes sub secciones. La primera 4.1.1 desarrolla como

se modifico el diseno de App Manager para lograr que este nuevo proyecto soporte diferentes

tipos de aplicaciones, tanto desde el punto de vista del diseno como de la implementacion de la

solucion. La segunda 4.1.2 esta enfocada en como se modifico el instalador tambien basandose

tanto en el diseno como en la implementacion de la solucion.

Por otro lado en la 4.2 se desarrolla el proceso que se requiere hacer para agregar soporte para un

nuevo tipo de aplicaciones en caso de ser necesario. En este caso se utilizaron como ejemplo las

aplicaciones WPF 3.3. Por ultimo en la seccion 4.3 se da una conclusion en base a lo desarrollado

a lo largo de este capitulo.

4.1. Diseno e implementacion del soporte para el despliegue de

aplicaciones

En esta seccion se va a contar como se llevo a cabo el diseno y la implementacion de un framework

que, basado en App Manager, permite conectar cualquier tipo de aplicaciones a la herramienta

antes mencionada y ası hacer uso de sus funcionalidades. Como se menciono anteriormente

App Manager estaba disenada e implementada para soportar solamente aplicaciones EUIJA. A

partir de esto se penso en generar una re implementacion, partiendo de la solucion existente,

para desarrollar una nueva herramienta. Este nuevo framework da la posibilidad, a partir de

la solucion anterior, de tener una herramienta a la que se le pueda conectar cualquier tipo de

aplicacion.

30

CAPITULO 4. DISENO E IMPLEMENTACION 31

A la hora de hablar del rediseno y la reimplementacion de la herramienta se tienen que diferenciar

dos grandes partes a tratar. La primera parte es sobre como se rediseno y reimplemento el back-

end y la interfaz de usuario (de ahora en mas UI) de App Manager, y la segunda es sobre como

se rediseno y reimplemento el proyecto encargado de generar los instaladores de cada aplicacion

conectada a App Manager.

4.1.1. Diseno e implementacion en App Manager

App Manager en sı fue la parte que menos afectada se vio en cuanto a cantidad o visibilidad

de cambios. Pero las modificaciones funcionales fueron importantes ya que aca es donde se

centraliza el proyecto. Antes de continuar comentando las modificaciones, se debe aclarar que

App Manager sigue un patron arquitectonico del tipo cliente servidor. Esta arquitectura se puede

definir como una arquitectura de software compuesta por el cliente y el servidor. Los clientes

siempre envıan solicitudes mientras el servidor responde a las solicitudes enviadas. Permite

que muchos usuarios tengan acceso a la misma base de datos al mismo tiempo. La base de

datos almacenara la informacion proporcionando una comunicacion entre los procesos [13]. La

herramienta App Manager estaba disenada para soportar solamente aplicaciones EUIJA y se

le debıa agregar soporte para otros tipos de aplicaciones. Por esta razon hubo que realizar una

serie de cambios, que se pueden dividir en dos grandes grupos. Los que afectan a la UI y los que

afectan al back-end. Todos estos cambios persiguen el mismo fin, que el proceso para agregar

soporte para nuevos tipos de aplicaciones sea lo mas sencillo posible.

4.1.1.1. Diseno e implementacion del Cliente

Del lado del cliente el primer cambio se ve al crear una nueva aplicacion en la herramienta

(Figura 4.1). Una vez iniciado sesion, el usuario puede crear una aplicacion, para esto debe

completar un formulario. Como muestra la figura 4.1 uno de los campos a completar es el tipo

de aplicacion que se esta creando. El primer cambio fue anadir los nombres de los nuevos tipos de

aplicaciones soportadas al formulario pero sobre todo dejar todo listo para que agregar nuevos

nombres de tipos de aplicaciones sea tan facil como agregar un campo String a una lista que

maneja el deslizable de la UI. Antes estos tipos estaban hardcodeados. Ahora, al tener que

permitir agregar nuevos tipos, se creo una lista que posee todos los tipos soportados y esta

lista es la que se muestra en el deslizable del formulario. De esta manera al anadir un nuevo

tipo de aplicacion solo se debe agregar una entrada nueva a la lista con el nombre del tipo

de esta aplicacion. Esta lista se encuentra tanto en el back end como en el front end ya que

para mostrarla en el deslizable que se observa en la figura 4.1 tambien se necesita esa lista y

actualizarla cada vez que se agregue soporte para un nuevo tipo de aplicaciones.

Este cambio sera fundamental luego para poder identificar los tipos de aplicaciones y poder

trabajar de manera diferenciada con ellos. Este cambio se vera reflejado en que, de ahora en

mas, cada servicio que realice App Manager debera analizar para que tipo de aplicacion es que

lo esta ejecutando y a partir de eso realizar trabajos de diferente manera dependiendo el tipo

CAPITULO 4. DISENO E IMPLEMENTACION 32

Figura 4.1: Interfaz de Usuario para la creacion de una aplicacion.

de aplicacion que sea. Del lado del cliente no se presentan mas cambios, ya que la idea principal

fue que se anada soporte para diferentes tipos de aplicaciones sin que el usuario final se vea

afectado por esto y ası se logro, ya que el unico cambio que notara el usuario sera que ahora

debera seleccionar el tipo de su aplicacion entre mas opciones.

4.1.1.2. Diseno e implementacion del servidor

A diferencia del cliente, la parte del servidor tuvo mas cambios. Un cambio importante que se

tuvo que realizar fue la configuracion del pipeline que se le conecta a la aplicacion del usuario una

vez que esta se conecta a la herramienta de la aplicacion que se esta conectando a la herramienta.

Hasta el momento, por solo tener soporte para aplicaciones EUIJA, este proceso no tenia mayor

complejidad. Este tipo de aplicaciones al crearse generan un archivo predefinido llamado “euija-

ci.yml” encargado de la generacion del pipeline IC/DC. Al modificar App Manager para que

soporte diferentes tipos de aplicaciones, un cambio drastico en el diseno que se produjo fue en

como se iba a llevar a cabo esta configuracion, ya que los demas tipos de aplicaciones no tendrıan

este archivo pero lo necesitaran para realizar dicha configuracion.

La manera de crear una aplicacion EUIJA es mediante una herramienta de linea de comandos

(de ahora en mas CLI). La figura 4.2 muestra los archivos que se crean al utilizar EUIJA

CLI para crear una aplicacion EUIJA. Se crean ciertos archivos necesarios para su correcto

funcionamiento. Entre ellos se crea un archivo llamado “.euija-ci.yml”. Este archivo es del tipo

yaml https://yaml.org/ y es el archivo que tiene la configuracion que describe los pipelines

en App Manager. Cuando una aplicacion se conecta a App Manager mediante su interfaz, la

herramienta busca en el repositorio original de la aplicacion del usuario este archivo, para poder

conocer la configuracion que deben manejar los pipelines.

Para proveer el soporte para cualquier tipo de aplicaciones, se presento el problema que cualquier

otro tipo de aplicacion que no fuese EUIJA no tendrıa este archivo y los pipelines no se crearıan.

CAPITULO 4. DISENO E IMPLEMENTACION 33

Figura 4.2: Directorio de una aplicacion EUIJA creada mediante el CLI.

Por esta razon se diseno una estrategia que involucre que cada vez que un usuario crease una

aplicacion en App Manager y la conecte con el repositorio Git que la contiene, App Manager

genera un repositorio espejo en un grupo de Gitlab. Este repositorio espejo lo que tiene es una

copia exacta y sincronizada del repositorio del usuario. Hasta aquı continua todo igual, ahora

bien, al poder tener diferentes tipos de aplicaciones, lo que debe hacer de App Manager al crear

este repositorio espejo, es consultar de que tipo de aplicacion se esta queriendo vincular. Como

se puede ver en la figura 4.3 para realizar esto se agregaron dos estructuras que se utilizaran

para dicho control:

Una lista. Se trata de una lista llamada “appsSupportted” de tipo String que tendra los

nombres de todos los tipos de aplicaciones soportadas. Esta lista es necesaria para el

recorrido y analisis de todos los tipos posibles soportados. Ademas, la informacion de esta

lista y porque su informacion sirve como clave, o parte de ella, del mapa. De esta manera

tambien se tiene en el proyecto una lista con todos los tipos de aplicaciones soportados

por App Manager.

Un mapa. Este mapa por cada tipo de aplicacion soportada tendra una entrada clave-valor.

La clave sera el tipo de la aplicacion, este se obtendra de la lista antes mencionada. Mientras

que el valor sera un Pair 1. Este Pair tendra el nombre de un archivo perteneciente a este

tipo de aplicaciones mientras que el otro valor del Pair sera una palabra clave a reconocer

dentro de el archivo especificado. Ası cada vez que se quiera reconocer el tipo de una

aplicacion se recorrera la lista de aplicaciones soportadas buscando la palabra reservada

en el archivo especificado. De esta manera cada vez que se agregue funcionalidad para

un nuevo tipo de aplicaciones se debera agregar una entrada para este nuevo tipo de

aplicaciones a la lista y al mapa de manera que, cada vez que se deba reconocer una

aplicacion de este nuevo tipo, esto sea posible.

Para poder soportar y conectar cualquier tipo de aplicacion se tuvieron que generar dos modi-

ficaciones principales:

1https://docs.oracle.com/javase/8/javafx/api/javafx/util/Pair.html

CAPITULO 4. DISENO E IMPLEMENTACION 34

Figura 4.3: Estructuras anadidas para la nueva solucion

La primera fue modificar uno de los principales Endpoints de la herramienta. Un endpoint

es el punto de entrada (Entrypoint) a la API, define la URL que los clientes deberan usar

para invocar a la API [5]. Este Endpoint es el que se encarga de conectar el repositorio

original del usuario con la herramienta. Su funcion es crear un repositorio espejo que

sera el que maneje la herramienta. Para esto, ahora que se soportaran diferentes tipos de

aplicaciones, era necesario reconocer cual es el tipo de aplicacion que se esta tratando de

conectar y realizar un chequeo para corroborar que ese tipo de aplicacion tuviese soporte

en la herramienta. Una vez chequeado esto se crea el repositorio espejo y se le agrega a

este repositorio la configuracion de IC/DC. Dentro de esta configuracion se agrega dentro

de las propiedades una que indica que archivo es el que tiene la configuracion de creacion

del pipeline. Este archivo, como se explico previamente, es un archivo que se anade al

repositorio espejo.

La segunda modificacion fue lograr que la herramienta soporte actualizaciones. Es decir,

que cada vez que el usuario realice cambios en su repositorio original de desarrollo App

Manager reconozca que se realizaron estos cambios y actualice el repositorio espejo. Esta

tarea era algo que la herramienta debıa tener desde antes pero esto no era ası. Para llevar

a cabo esta tarea lo que se hizo fue anadir un webhook al repositorio original del usuario.

Un webhook es un conector, como una API. La diferencia que hay entre estos dos es que

el webhook se basa en eventos. A diferencia de las API que esperan un request para dar

una respuesta, los webhooks se activan al “escuchar” un cambio [20]. De esta manera al

crear un webhook en el repositorio original del usuario este va a “escuchar” cuando se

realiza un cambio en el repositorio y va a informarlo. Una vez que escuchamos ese cambio

debemos actualizar el repositorio espejo y ası mantendremos actualizada la aplicacion en

la herramienta.

Para resolver el primero de los dos puntos marcados se necesitaron agregar dos estructuras al

proyecto. Estas dos nuevas estructuras permitiran que al generar el repositorio espejo se analice

que tipo de aplicacion se esta manejando y, de no ser una aplicacion EUIJA y, por lo tanto,

no tener el archivo .Euija-ci.yml, este se genere. Para esto se tendra un archivo .yml para cada

tipo de aplicacion soportada con la configuracion necesaria para generar el pipeline IC/DC de

CAPITULO 4. DISENO E IMPLEMENTACION 35

esta y se le agregara este archivo al repositorio espejo al generarlo. Para resolver todo el nuevo

funcionamiento de la plataforma fue necesario anadir algunos nuevos metodos y modificar otros

ya existentes.

El primero metodo agregado es el encargado de cargar las estructuras que se anadieron al

proyecto. Como es algo estatico, lo unico que debe hacerse cada vez que se agregase soporte

para un nuevo tipo de aplicacion seria anadir nuevas entradas a estas estructuras. En el

Algoritmo 4.1 Pseudocodigo para cargar los tipos soportados de aplicaciones.

private setSupportedApps() {List appSupported = {“Euija”, “Wpf”} // Carga de tipos soportadosMap<String, Pair<String,String>> posibleApps,anadirAposibleApps (“Wpf”, <“nombre file”,”nombre pal reservada”> // Carga de archivo ypalabra a buscar para aplicaciones WPF.anadirAposibleApps (“Euija”, <“nombre file”,”nombre pal reservada”>;}

algoritmo 4.1 se puede observar que este metodo es simplemente un metodo privado donde

se cargan las estructuras. Se puede ver tanto el caso de aplicaciones EUIJA como tambien

con otro ejemplo como podrıan ser aplicaciones WPF. Se puede ver como por cada tipo de

aplicacion hay una entrada a la lista que lleva el nombre del tipo y una entrada al mapa. Si

tomamos el caso de las aplicaciones EUIJA podemos ver que posee como clave la palabra

“Euija” mientras que el Pair esta compuesto por la palabra “bundle” que seria la palabra

a buscar en el archivo y la otra entrada del par es “filename:bnd.bnd” que es la manera

de referenciar el file donde se debe buscar la palabra reservada al hacer el request al la

API de Gitlab. Este metodo tiene la propiedad de ser “@PostConstruct” esto significa que

cuando se instancia el servicio el metodo se ejecuta automaticamente.

El segundo metodo que se anadio fue el metodo getType(String owner, String appname).

Este metodo publico es el encargado de, dado el dueno del repositorio y el nombre de la

aplicacion que se quiere analizar, devolver siempre y cuando sea una aplicacion soportada

por la herramienta, el tipo de la aplicacion en cuestion. El objetivo del algoritmo 4.2 es

obtener el tipo del repositorio que se esta queriendo conectar a un aplicacion creada en App

Manager. Para esto, mediante un bucle que recorre la lista de todos los tipos soportados, se

crea un request por cada pasada del bucle utilizando la librerıa OkHttp https://square.

github.io/okhttp/. Este request le pide a la API de Gitlab https://docs.gitlab.com/

ee/api/ que le devuelva el repositorio correspondiente solo si en el repositorio se encuentra

un archivo especifico con una palabra especifica (informacion que tenemos en mapa cargado

en el algoritmo 4.1). Una vez que obtenemos la respuesta de ese request, si la respuesta es

exitosa y en ella esta el repositorio, se puede afirmar que el tipo del repositorio es correcto

y lo retornamos. Si la respuesta devuelve un JSON vacıo se debe a que el repositorio no

es del tipo que se analizo y se analiza el siguiente tipo. Una vez que se recorrio toda la

lista de posibles aplicaciones y en el repositorio a conectar no se reconocio ninguno de los

archivos especıficos sera porque ese repositorio no es de ningun tipo soportado por App

CAPITULO 4. DISENO E IMPLEMENTACION 36

Algoritmo 4.2 Pseudocodigo para obtener el tipo de una aplicacion.

getType(,Repositorio a conectar ) {for tiposSoportados {request = createRequest(repo);if (responseIsSuccesfull(request){if(repoTypeIsValid()){return repoType}}else (check next)}else {return error}}}

Manager y se devolvera un error debido a esto. Por esta razon se creo un excepcion llamada

“AppNotSupportedException” que es lo que se devolvera en ese caso.

Con el metodo de la aplicacion identificado ya se puede saber cual es el archivo con la

configuracion del pipeline IC/DC correspondiente que debemos copiar en el repositorio.

Como se explico anteriormente las aplicaciones EUIJA ya generan este archivo al crearse,

Algoritmo 4.3 Pseudocodigo que chequea tipo de aplicacion y crea el Yalm especifico.

setCiYalm(appType, Repository repo){yamlContent = createYamlContent(appType);addCIFileToRepo(repo, YamlContent);}

por lo que no debemos tenerlas en cuenta a la hora de cargarles ese Yaml. En cuanto a todas

las demas aplicaciones soportadas lo que se hace es generar un JSON https://www.json.

org/json-es.html con el cuerpo del request donde se cargara la informacion necesaria

para realizar este request del tipo POST. Como se puede observar en el algoritmo 4.3 de

este metodo lo primero que se hace es generar un String que contendra el contenido de

el archivo a subir. Este archivo debe encontrarse entre los recursos del proyecto y cada

vez que se le de soporte a un nuevo tipo de aplicaciones se debe anadir a los recursos el

archivo correspondiente a este nuevo tipo. Una vez hecho esto al igual que en el metodo

explicado anteriormente se utiliza la API de Gitlab para enviar el request necesario y

cargar el archivo en el repositorio.

Para explicar como se mantiene la aplicacion actualizada mediante el webhook se utilizara el

algoritmo 4.4. Lo que se hizo fue crear un webhook en el repositorio original de la aplicacion del

usuario para el webhook en cuestion envıe un mensaje cada vez que este repositorio es actuali-

zado. Para hacer esto, al momento de crear el repositorio espejo, se crea tambien un webhook

en el repositorio original siempre y cuando el repositorio espejo se haya creado correctamente.

Desde el metodo de creacion del repositorio espejo se llama al metodo “createWebHookInProvi-

CAPITULO 4. DISENO E IMPLEMENTACION 37

Figura 4.4: Interfaz gitProvider y sus implementaciones

Algoritmo 4.4 Pseudocodigo de la creacion del webhook en el repositorio original

void createWebHookInProvider(Application app) {branch = getDefaultBranch()repository = app.getRepository()provider = reposotory.getProvider()provider.createWebhook(repository.getPath(), app.owner)}

Algoritmo 4.5 Pseudocodigo del metodo updateMirrorRepository

public String updateMirrorRepository(String owner, String mirrorRepoName, String cloneUrl,String branch){mirrorRepository = getMirrorRepository(mirrorRepoName)if (mirrorRepositoy.exists(){orginalRepo = Git.getRepository(cloneURL)mirrorRepository.clone(originalRepo)mirrorRepository.forcePush()mirrorRepository.delete(originalRepo)}}

CAPITULO 4. DISENO E IMPLEMENTACION 38

der” base enviando como parametro la aplicacion que se esta conectando a la herramienta. La

primera accion que realiza este metodo es la de obtener el branch por defecto de esta aplica-

cion( normalmente se trata del branch master pero esto puede no ser asi) mediante el metodo

“getDefaultBranch”. Una vez reconocido este branch donde se va a crear el webhook, el metodo

se encarga de reconocer el provider del repositorio original mediante el metodo “getProvider”,

esto se debe a que la configuracion del webhook se realiza de diferente manera para cada uno de

ellos (Github, Gitlab y Bitbucket). Habiendo obtenido el provider y teniendo el repositorio de la

aplicacion original (se encuentra dentro de la aplicacion que llega como parametro) se llama al

metodo “creteWebhook” con los parametros owner (es el dueno del repositorio) y repoPath (con

la ruta al repositorio original). Este metodo corresponde a una interfaz del proyecto llamada

GitProvider la cual es implementada por las clases especificas de cada provider como se puede

ver en la figura 4.4. Con el webhook registrado en el repositorio del usuario cada vez que se

registre en el branch default un cambio el webhook, se envıa un request avisando de este. Este

request activa al metodo 4.5 que tiene como parametros el owner (es el dueno del repositorio),

el branch (el nombre del branchdefault), el nombre del repositorio y la URL del repositorio

original. Con toda esta informacion primero se chequea si el repositorio espejo existe. Si existe

se clona en este el repositorio original mediante el metodo “clone”. Luego realizando un force

push https://git-scm.com/docs/git-push del repositorio original en el repositorio espejo es-

te ultimo queda actualizado con los ultimos cambios. Para finalizar elimino el repositorio original

que habıa clonado del repositorio mediante el metodo “delete”. De esta manera es que siempre

se mantiene actualizado el repositorio espejo con respecto al original.

Con todo lo desarrollado hasta el momento ya se tiene la herramienta lista para poder agregar

soporte para diferentes tipos de aplicaciones. A modo de resumen se puede identificar dos pasos

que se deben realizar por la parte del back-end. Es por esto que cada vez que se desee agregar

soporte para un nuevo tipo de aplicacion los pasos que se deben seguir son:

1. Anadir las entradas a la lista y al mapa para el tipo de aplicacion en cuestion.

2. Anadir el archivo .yml a los recursos del proyecto con el siguiente nombre: “tipo de apli-

cacion”+ “.yml” como por ejemplo “Euija.yml”.

4.1.2. Diseno e implementacion del Instalador

App Manager presenta la opcion de descargar un instalador auto generado de la aplicacion que

el usuario conecta a la herramienta. Esto ocurre siempre y cuando al correr el pipeline IC/DC

este termine su progreso de manera exitosa. Al igual que App Manager, el proyecto encargado de

desarrollar este instalador estaba disenado solamente para generar instaladores para aplicaciones

EUIJA por lo que hubo que hacer un re-diseno del mismo. El instalador, a diferencia de App

manager, que no se vio modificada en demasiados aspectos, fue modificado en su mayorıa. Esto

se debe a que estaba implementado de manera que solo podıa seguir el ciclo de instalacion de una

aplicacion EUIJA, mas precisamente el codigo estaba desarrollado de tal manera que era una

CAPITULO 4. DISENO E IMPLEMENTACION 39

secuencia de pasos especıficamente disenados para poder realizar la instalacion de una aplicacion

EUIJA. De esta manera solo realizaba tareas especıficamente necesarias para la instalacion de

este tipo de aplicaciones, ademas de las tareas comunes a cualquier instalador como puede

ser crear un directorio o un desinstalador. El problema que tenia esto era que siguiendo esa

logica, por cada tipo de aplicacion que tuviese soporte en App Manager se deberıa hacer lo

mismo generando una repeticion de codigo innecesaria. Debido a esto y analizando que, sin

importar el tipo de aplicacion que se quisiese instalar hay acciones comunes a realizar en todas

las instalaciones de un software, se llego a la conclusion que se podıan abstraer diferentes tareas

y re utilizar para que no se vean re-implementadas si se deseaba agregar soporte para otro tipo

de aplicaciones en un futuro.

Algo importante a mencionar, es que el instalador utilizaba, y sigue utilizando (ya que en la

nueva solucion se mantuvo esto), la librerıa de Chromium Embededd Framework (de ahora en

mas CEF) https://bitbucket.org/chromiumembedded/cef/src/master/README.md.

CEF es un proyecto de codigo abierto con licencia BSD fundado por Marshall Greenblatt en 2008

y basado en el proyecto Google Chromium http://www.chromium.org/. A diferencia del propio

proyecto Chromium, que se centra principalmente en el desarrollo de aplicaciones de Google

Chrome, CEF se centra en facilitar casos de uso de navegadores integrados en aplicaciones de

terceros. CEF aısla al usuario de la complejidad subyacente del codigo Chromium y Blink al

ofrecer API’s estables de calidad de produccion, ramas de lanzamiento que rastrean versiones

especıficas de Chromium y distribuciones binarias. La mayorıa de las funciones de CEF tienen

implementaciones predeterminadas que brindan una gran funcionalidad al tiempo que requieren

poco o ningun trabajo de integracion por parte del usuario. Actualmente hay mas de 100 millones

de instancias instaladas de CEF en todo el mundo integradas en productos de una amplia gama

de empresas e industrias. En el caso del instalador, CEF se utiliza para levantar al UI de este.

De esta manera, utilizando CEF se obtiene un navegador integrado, esto es una interfaz web

para el instalador, presentando algo mas moderno y facil de utilizar para los usuarios.

Otro punto que no cambio, al igual que el uso de CEF, fue el lenguaje en el que estaba im-

plementado el instalador: Rust. Rust es un lenguaje multi-paradigma; soporta programacion

funcional, imperativa y orientada a objetos. Esta orientado a la performance y la seguridad,

que incluye muchas tecnicas probadas en otros lenguajes, mientras que al mismo tiempo intro-

duce mejoras substanciales en el area de seguridad comparado a lenguajes como C++ https:

//blog.rust-lang.org/2014/10/30/Stability.html. Lo que hace unico a Rust es que com-

bina el rendimiento de un lenguaje de bajo nivel como es C con la gestion de seguridad de la me-

moria de los lenguajes de alto nivel como por ejemplo BASIC https://www.rust-lang.org/es.

Rust provee un uso de la memoria muy eficiente estableciendo la vida util de cada variable de

manera tan eficiente que resulta innecesario el uso de un Garbage Collector (recolector de ba-

sura) en el lenguaje[12]. Otra cosa que hace unico a este lenguaje es que tiene las garantıas de

seguridad de un lenguaje que tiene garbage collector sin tenerlo obteniendo una performance

comparable con la de C. Actualmente un desarrollador tiene la opcion de utilizar las versio-

nes estables, beta o las versiones nocturnas, actualizadas diariamente con lo ultimo del codigo,

CAPITULO 4. DISENO E IMPLEMENTACION 40

lo que permite probar nuevas caracterısticas, y tambien nuevas correcciones, a medida que la

comunidad desarrolla el lenguaje. Es importante aclarar que a pesar de pasar por una baterıa

de pruebas, y que son ampliamente usadas por los desarrolladores, las versiones nocturnas no

son consideradas versiones estables. Cada seis semanas las versiones nocturnas se convierten

en beta, y luego de un proceso de pruebas estas se convierten en estables, pero no todas las

funcionalidades de las versiones nocturnas pasan a serlo. En las versiones nocturnas se prueban

nuevas caracterısticas para permitir una rapida evolucion del lenguaje y luego de la etapa de

prueba y refinamiento no todas son aceptadas en el lenguaje. Las principales caracterısticas que

hacen de Rust un lenguaje con excelente aceptacion a nivel mundial desde el 2016 en adelante

son las protecciones contra las “race conditions” en programas multi-hilo, la seguridad en la ad-

ministracion de memoria, y su velocidad, comparable con otros lenguajes considerados de bajo

nivel, como C. La necesidad de un lenguaje como este ya podıa ser apreciada apenas cinco anos

luego de su creacion, cuando se empezaba a posicionar en los primeros puestos de las estadısticas

de crecimiento de uso entre distintos lenguajes de programacion afianzandose como el lenguaje

mas amado por los programadores teniendo un 86 % de votos positivos de los 65000 partici-

pantes de la encuesta. https://tinyurl.com/4965tz9phttps://tinyurl.com/69axpuvb. Por

estas razones es que se tomo la decision de utilizar este lenguaje para desarrollar el instalador.

Figura 4.5: Diagrama del proyecto del instalador antes de ser modificado.

Para mostrar los cambios en el diseno del instalador analizaremos una serie de diagramas (se-

cuencia y clase) para entender mejor como era el proceso para crear el instalador antes y como es

ahora con las modificaciones realizadas. El proyecto del instalador estaba compuesto por cuatro

archivos principales como se puede observar en la figura 4.5 main, app, browser y binaries y

algunos archivos complementarios como es el caso de lib.

build: funciona como un pre procesador. En tiempo de build lee los archivos requeridos

por el runtime del instalador (como HTML, DLLs, pak, etc), los comprime y los guarda

como un array de bytes en el archivo binaries que luego es compilado normalmente. Luego

cuando se ejecuta el instalador extrae esos arrays de bytes, previo a descomprimir en los

files finales.

binaries: es el archivo encargado de empaquetar todos los archivos comprimidos necesarios

para que el usuario final ejecute el instalador (que le llegan desde el archivo build) en el

CAPITULO 4. DISENO E IMPLEMENTACION 41

Figura 4.6: Diagrama de secuencia instalador original.

binario final. Estos son los archivos que tienen la logica de la instalacion como tambien los

archivos complementarios (archivos de cef, html, DLLs, etc). Estos archivos empaquetados

luego seran desempaquetados al momento de la instalacion. Esto funciona de esta manera

para que el instalador anada al build del instalador especifico de un tipo X de aplicacion

solamente los archivos que ese tipo de aplicacion necesita generando un instalador lo mas

portable posible.

app: esta es el archivo que tiene toda la logica con los pasos a seguir para realizar la

instalacion de una aplicacion EUIJA. En este mediante un canal de mensajes que se van

actualizando dependiendo del mensaje que llegue hay que realizar uno u otro paso de la

instalacion.

browser: este es el archivo donde se realiza toda la funcionalidad especifica de ejecu-

cion del instalador. Pero tambien se hace todo el trabajo de fondo que se necesita para

que este instalador funcione, esto es: (i) se descargan los archivos necesarios de Digital

Ocean https://www.digitalocean.com/; (ii) se crean los archivos locales necesarios; (iii)

se informa de cualquier error que vaya surgiendo durante la instalacion; (iv) se envıan los

mensajes necesarios para que la interfaz de usuario los comunique; (v) se configuran to-

das las configuraciones necesarias para la Interfaz de usuario, tamano, posicion, etc. Otra

funcion muy importante que tenia este archivo era la de inicializar CEF 4.1.2 como se

explico anteriormente CEF es fundamental para el funcionamiento del instalador ya que

se encarga de muchas cosas en el proyecto como por ejemplo la descarga de los binarios de

la aplicacion del usuario necesarios para la instalacion de la misma .

main: este es el archivo principal del proyecto. Este archivo es la encargado de desempa-

CAPITULO 4. DISENO E IMPLEMENTACION 42

quetar el archivo ejecutable propio de la aplicacion y todos los binarios que se necesitan

para correr la aplicacion, como es el caso de browser y los demas archivos empaquetados

por binaries.

En la figura 4.6 que contiene el diagrama de secuencia original, se observa como el archivo browser

era el encargado de practicamente toda la funcionalidad para la creacion del instalador. En este

archivo se realizaban todas las tareas que iba a ejecutar luego el binario del instalador, desde la

creacion de un directorio donde se alojarıan todos los archivos necesarios para correr la aplicacion,

pasando por la creacion de un acceso directo en el escritorio y hasta un desinstalador. Cuando

el browser era desempaquetado por el archivo main para poder ejecutarse, en ese momento

realizaba todas las llamadas a los metodos de la librerıa de CEF como por ejemplo cef settings()

donde se configuraban todas las cosas necesarias para levantar la UI del instalador. El diseno

del instalador tenıa dos archivos principales, browser y App. Estos dos archivos, junto con otros

archivos secundarios (como son lib.rs y binaries.rs) abarcaban todo el diseno del instalador.

Como el proyecto en si estaba destinado solamente a ser una herramienta para generar instala-

dores para aplicaciones Euija unicamente, se realizaron todas las tareas necesarias y prioritarias

del instalador en este archivo (Browser) ya que no habıa necesidad de abstraer ninguna funcio-

nalidad, pero con la nueva solucion eso cambio. Es por eso que quien tuvo mayores cambios fue

obviamente el archivo browser por ser quien tenia mayormente toda la funcionalidad especifica

de como iba a funcionar, paso a paso, el instalador. De todas maneras, todo el proyecto en si se

vio afectado en su mayorıa.

A la hora de re disenar el instalador lo que se penso fue en desarrollar una solucion que tuviese

como principal objetivo el hecho de que la tarea de agregar soporte para un nuevo tipo de

aplicaciones fuese lo mas sencilla posible y que no haya que modificar logica del codigo mas

que la necesaria para agregar soporte para los nuevos tipos de aplicaciones. Lo que se quiere

decir con esto es que el hecho de agregar un nuevo tipo de aplicaciones no afecte al codigo

anterior ni tenga que sufrir modificaciones. Para esto hubo que realizar una re-estructura general

para que el software funcione de manera eficiente y sea sencillo tener una solucion general y

poder agregar, cada vez que sea necesario, un nuevo archivo para soportar un nuevo tipo de

aplicaciones. Por esto es que el nuevo diseno quedo como se muestra en la figura 4.7, donde

se observa como quedo la estructura de los cambios que se hicieron. Lo primero que se realizo

fue identificar las partes comunes que presenta un instalador, sea del tipo que sea, para poder

separarlas en un archivo llamado Installer que es el que va a manejar estas funcionalidades

comunes a todos los instaladores (generar un directorio, crear un acceso directo en el escritorio,

generar un desinstalador, etc). Una vez hecho esto, se tomo la decision tambien de quitar toda

la funcionalidad referida a CEF de el archivo browser e integrarla en un nuevo archivo llamado

cefHandler, de esta manera si los archivos especıficos de cada tipo soportado necesitan tareas

especificas de CEF importaran este archivo para utilizar sus funcionalidades especificas y browser

solo se encargarıa de su funcionalidad.

Como muestra en la figura 4.7 , la estructura ahora es la siguiente:

CAPITULO 4. DISENO E IMPLEMENTACION 43

Figura 4.7: Diagrama actualizado del proyecto instalador.

Main: no se vio modificado.

build: este es uno de las archivos que se vio afectado por los cambios. Ya que ahora al

soportar mas tipos de aplicaciones y al encargarse de la pre compilacion del proyecto debe

ser capaz de identificar para que tipo de aplicaciones se esta creando el instalador para

que, dependiendo de esto, se genere la solucion correcta.

installer: este nuevo archivo es el que reemplaza a app. Es el encargado de realizar las

tareas comunes a todos los instaladores, entre ellas se encuentran la creacion del directorio

de la aplicacion, la creacion de un desinstalador, la creacion de un acceso directo en el

escritorio. Ademas tendra la tarea de controlar el vector con las tareas especificas de cada

instanciacion y llevarlas a cabo.

cefhandler: este nuevo archivo sera el que que utilizaran todos los tipos de aplicaciones

que sean soportados por App Manager. En este se abstrajo toda la funcionalidad de 4.1.2

que presentaba anteriormente el archivo browser. Ahora cada vez que cualquier tipo de

aplicacion necesite de algun servicio de CEF debera invocar a las funciones que esten

en este archivo, de haber mantenido esta funcionalidades adentro del archivo browser, se

generarıa una repeticion de codigo por cada tipo de aplicacion que soporte App Manager.

binaries: no se vio modificado.

Euija: tiene la logica de las tareas especificas que necesita el instalador de este tipo de

aplicaciones.

browser: como se explico al hablar de el archivo cefHandler, browser se vio bastante afec-

tado a los cambios anadidos. Paso de tener por completo la funcionalidad del instalador a

enfocarse solamente en ser la instanciacion para las aplicaciones EUIJA, ya que todos los

metodos que eran propiamente de 4.1.2 y eran utilizados en este metodo fueron eliminados

CAPITULO 4. DISENO E IMPLEMENTACION 44

y anadidos a cefhandler por lo explicado anteriormente. A su vez, continua teniendo la

funcionalidad de ser el encargado de iniciar el sub proccess helper cuando el instalador

es instanciado para otro tipo de aplicaciones que no sean las aplicaciones EUIJA. Este

sub process helper es el encargado de inicializar CEF y realizar todas las tareas que se

le soliciten a CEF por eso que en cualquier caso debe ser utilizado, ya que sea el tipo de

aplicacion que sea, CEF es utilizado.

Para pasar a explicar como se implementaron los cambios que se acaban de marcar se seguira

la misma logica que con App Manager. Se explicara mediante una comparacion de como estaba

anteriormente y como fue modificado este proyecto para generar un instalador. El principal

objetivo que perseguıan las modificaciones realizadas fue que, cada vez que se le debiese agregar

soporte para un nuevo tipo de aplicaciones, este proceso sea lo mas sencillo posible y se deba

modificar el proyecto lo menos posible. Tal que anadir soporte para un nuevo tipo de aplicaciones

sea lo mas sencillo dentro de las posibilidades. De todas maneras, a pesar de sufrir muchos

cambios, mayormente estos estuvieron en la re-estructuracion del proyecto ya que como se explico

en la seccion 4.1.1 la funcionalidad se encontraba centralizada en un archivo que de no haberse

modificado hubiese sido imposible obtener una abstraccion del mismo. Para comenzar, lo primero

que se hizo fue actualizar el proyecto a la nueva version de Rust (Rust 2018 https://doc.

rust-lang.org/edition-guide/rust-2018/index.html). Al actualizar la version de Rust en

el proyecto hubo que modificar el manejo de comunicacion entre los archivos. Antes si se querıan

utilizar metodos de un archivo“hermano”se debıa crear una carpeta con un archivo mod adentro.

como era el caso de “App” en la version anterior, mientras que ahora esto no es mas necesario

sino que para compartir funciones entre archivos estas ademas de ser publicas, el archivo debe

ser publico y esto se hace como se muestra en la figura 4.8 de el archivo lib.

Figura 4.8: Importacion de los diferentes archivos en el proyecto.

En la figura 4.9 se observa como con las modificaciones realizadas las tareas que realiza el

proyecto estan mas divididas. Esto es lo que se busco con el fin de lograr separar todas las tareas

comunes que presenta un instalador de las tareas especıficas de un instalador disenado para un

tipo de aplicaciones x. Se puede ver como, por ejemplo las tareas que debe realizar CEF ahora se

le solicitan al archivo cefhandler y no a browser. Lo mismo que las tareas especificas de cualquier

tipo de instalador que ahora se le pediran a su archivo especıfico, en el caso de este diagrama

podemos ver el ejemplo de un instalador para aplicaciones Euija. Esto se puede ver ya que

llamadas que antes hacia browser como por ejemplo la de iniciar CEF (init cef()) ahora, cuando

lo llama instaler, las hace el archivo cef handler. Lo mismo pasa con cef settings(). Mientras

CAPITULO 4. DISENO E IMPLEMENTACION 45

que todas las tareas especificas de un instalador Euija seran llamadas a metodos de el archivo

Euija como se puede ver en el diagrama. De esta manera cuando se tenga que empaquetar el

proyecto para ejecutar un instalador Euija solamente se empaquetara con los binarios necesarios

para ese tipo de aplicaciones. Haciendolo de esta manera mucho mas chico que si tuviese todo

lo necesario para todo tipo de aplicaciones y sea mas sencillo de distribuir.

Figura 4.9: Diagrama de secuencia del proyecto modificado.

Ahora se puede decir que el funcionamiento en sı de el instalador gira entorno al archivo installer

donde se crea un trait llamado Steper. Los traits no son mas que una lista de metodos, con o

sin implementacion, que las estructuras o los tipos deben implementar para cumplir ese trait.

Se definen con la palabra clave trait y una lista de funciones que definen la interfaz y luego se

implementa con la construccion “impl TRAIT for TYPE”.

Este trait tiene una funcion execute que es la que cada archivo de cada tipo de aplicacion

soportada instanciara tantas veces como tareas tenga que realizar el instalador que no sean

comunes a todos los instaladores. Las tareas comunes, como no es necesario reescribirlas por

cada archivo, estan directamente implementadas en installer.

Este trait esta implementado en el archivo installer. En este se encuentran dos metodos princi-

pales.

Execute (&Self, transmiter: Sender<Msg>) es la funcion abstracta que cada archivo es-

CAPITULO 4. DISENO E IMPLEMENTACION 46

pecıfico para cad tipo de aplicacion que se cree debe implementar. El primer parametro

es un parametro propio de la implementacion de traits y debe enviarse siempre como

cualquier parametro normal aunque nunca se utilice en la implementacion. El segun-

do se trata de una librerıa que se encarga de mantener un canal de mensajes llama-

da mpsc https://doc.rust-lang.org/std/sync/mpsc/. Este canal puede tener muchos

emisores de mensajes (Senders) pero un solo receptor de estos (Receiver) que sera el que

maneje el flujo de estos y decida que hacer cada vez que llegue uno. Este receptor lo tendra

installer.rs. En la figura 4.10 podemos observar como es la estructura de un mensaje donde

Figura 4.10: Estructura de un mensaje.

cada tarea que se vaya haciendo va a ir notificando diferentes mensajes como por ejemplo

cuando se termino de configurar todo y es momento de levantar la interfaz de usuario y

comenzar con la instalacion en la computadora del usuario la variable boleana launch se

pondra en verdadero.

Init (steps: Vec<S>, html path: &str, application name: &String, cefrust path: &path-

Buf). Esta funcion es la que posee el receptor de mensajes del que ya hablamos y el que

manejara el hilo de ejecucion de creacion del instalador para cada tipo de aplicaciones

soportadas. Este init tendra dos tareas principales. La primera es levantar CEF 4.1.2 pa-

ra esto es que se le pasa como parametro la ruta de donde se encuentra almacenada la

carpeta .swtcef (cefrust path). Esta carpeta es la que se encarga de comprimir el archivo

build 4.1.2 y descomprimir en la ejecucion del instalador. CEF luego sera utilizado durante

toda la ejecucion para diferentes configuraciones como tambien para realizar diferentes re-

quest. Mientras que la otra tarea principal que tiene es la de controlar el flujo de mensaje

mediante el receiver y decidir que hacer respondiendo a cada uno.

Cada archivo correspondiente a cada aplicacion llamara al metodo init con el vector de steps la

ruta a la carpeta de CEF el nombre de la aplicacion a la que se le esta por crear el instalador

y una ruta de destino donde quedara almacenado todo el contenido necesario para correr la

aplicacion. El vector que se le esta pasando como parametro es un vector del tipo Steper, es

decir que adentro tendra los pasos especıficos de el tipo de instalador que se esta creando.

CAPITULO 4. DISENO E IMPLEMENTACION 47

Cada archivo especıfico para cada tipo de aplicacion re implementa el metodo execute haciendo

que este realice la tarea necesaria. Siempre que sean tareas que no sean comunes a todos los

instaladores, como es el caso de generar el directorio de la aplicacion, generar un desinstalador,

generar un acceso directo en el escritorio (si es que el usuario lo desea).

El vector que le envıa cada archivo mediante el metodo init a installer es leıdo por el controla-

dor de mensajes que va leyendo uno a uno los componentes del vector y realizando las tareas

que estos demanden. Estos mensajes que va recibiendo sirven para saber como continuar y de-

mas informacion complementaria (avance de la instalacion, si llego a su fin, si fallo, etc). A

su vez tambien ejecutara las tareas comunes necesarias para cualquier instalador que por estar

implementadas en installer no es necesario que esten dentro del vector. Este ciclo se maneja

mediante el receptor de mensajes y cada mensaje que va llegando sirve para saber como conti-

nuar con cada uno de los eventos diferentes. Esto se debe a que el ciclo depende de un metodo

de CEF llamado cef do loop work() https://bitbucket.org/chromiumembedded/cef/wiki/

GeneralUsage#markdown-header-message-loop-integration que permite que se integre con

un controlador de mensajes como el que se esta usando y maneje el ciclo.

A partir de ahora, con estos cambios, se deja de tener un proyecto para crear instaladores para

aplicaciones EUIJA para pasar a tener un proyecto generico para crear instaladores para cual-

quier tipo de aplicacion soportada por App Manager. Lo que se genera son diferentes ejecutables

dependiendo del tipo de instalador del que se quiera obtener. Es decir que si lo que se desea crear

es un instalador para aplicaciones EUIJA se debe hacer un build unicamente los archivos nece-

sarias para esto, de esta manera lo que logramos es obtener un ejecutable mucho mas portable

que uno con soporte para todos los tipos de aplicaciones soportados por App Manager.

Este binario que se acaba de crear, ası como cada binario para cada tipo de aplicacion so-

portada, se almacenara en un servidor en la nube provisto por Digital Ocean https://www.

digitalocean.com/. Por cada tipo de aplicacion soportada se creara un space (Un space es un

servidor que nos permite almacenar una amplia cantidad de contenido estatico sin estructura)

que contendra el ejecutable del instalador correspondiente. Hay que tener en cuenta tambien que

pueden existir dos tipos de aplicaciones diferentes que sigan el mismo flujo de instalacion y nece-

siten de los mismos requerimientos para instalar una aplicacion por lo que no serian necesarios

dos binarios diferentes sino que se podrıa reutilizar el mismo.

|

Figura 4.11: Etapa de descarga del instalador auto generado.

En la figura 4.11 se pueden observar dos ramas diferentes de una misma aplicacion. Al ser una

exitosa y la otra no, la exitosa permite la descarga de un instalador mientras que la otra no. A su

CAPITULO 4. DISENO E IMPLEMENTACION 48

vez se puede observar que ademas del boton para descargar el instalador se tiene un hipervınculo

que de cliquearlo este te redirecciona a una a una pagina web que se genero automaticamente

con la informacion de tu aplicacion. Nombre de la misma, quien la creo (organizacion), una

descripcion (la que se le dio a la aplicacion al crearla como se vio en figura 4.1). Esta pagina sera

la que se les proporcionara a los usuarios finales de la aplicacion. Se creo para, de una manera

muy sencilla para el desarrollador, distribuir la aplicacion teniendo presente la informacion de

la misma y su instalador para descargar.

Con esto, podemos definir una serie de pasos a seguir a la hora de querer agregar soporte al

instalador para un nuevo tipo de aplicaciones.

1. Reconocer los archivos necesarios para ejecutar cualquier aplicacion del nuevo tipo en

cualquier terminal.

2. Desarrollar el archivo con las tareas especificas que debe cumplir el instalador para el tipo

de aplicaciones en cuestion.

4.2. Instanciacion

Para poder demostrar lo sencillo que es, gracias a el trabajo realizado en este proyecto de tesis,

anadir soporte para un nuevo tipo de aplicaciones se genero una instanciacion en la que se le dio

soporte en App Manager a aplicaciones WPF. Tambien sirvio a su vez a modo de testeo para

reconocer fallas o ineficiencias en la solucion implementada. Lo primero que se hizo para poder

iniciar con el proceso fue crear una simple aplicacion WPF que iba a funcionar de prueba a la

hora de anadirla a App Manager. Consta de una simple aplicacion para anadir y eliminar usuarios

a una tabla. Una vez creada la aplicacion se realizaron las diferentes tareas para continuar con

el ciclo de vida de la misma para luego poder generar conclusiones al respecto. Se conecto la

aplicacion a Gitlab y se utilizaron sus servicios para generar un pipeline IC/DC. Tambien se creo

un instalador de manera de reconocer las tareas que se debieron llevar a cabo para luego generar

la instanciacion. Una vez hecho esto se paso a realizar la instanciacion de las aplicaciones WPF

en la herramienta, completando los pasos a seguir tanto en App Manager como en el instalador.

4.2.1. App Manager para WPF

Como se explico en la seccion 4.1 cada vez que se quiere agregar soporte a un nuevo tipo

de aplicaciones, gracias a este trabajo, el proceso es muy sencillo. Consta simplemente de dos

pasos. En el primero de los puntos se debe identificar algun archivo especıfico de aplicaciones

WPF que se este seguro que toda aplicacion WPF lo tendra. Puede pasar que haya otro tipo

de aplicaciones que sean de caracterısticas similares y sigan el mismo ciclo que otras por lo

que pueden ser reconocidas mediante el mismo archivo y tambien sigan la misma secuencia de

pasos a la hora de crear el instalador por lo que pueden ser tomadas como iguales y no seria

CAPITULO 4. DISENO E IMPLEMENTACION 49

necesario generar una nueva instanciacion. En el caso de las aplicaciones WPF se reconocio

que siempre debe existir un archivo con “nombre de la aplicacion” y la extension “.csproj” es

decir, si la aplicacion se llamase hola mundo debe existir un archivo“hola mundo.csproj”. Dentro

de este file se reconocio que siempre debe estar presente el String “settings.setting”. Por estas

dos razones es que a las estructuras creadas y explicadas en la seccion 4.1 como son la lista

y el mapa para poder soportar aplicaciones WPF se les tuvo que agregar a la lista la entrada

Wpf y a el mapa dos entradas para poder soportar aplicaciones WPF. La primera entrada

fue el conjunto clave-valor <”Wpf”, ”settings.settings”>, mientras que la segunda entrada fue

<”WpfFile”,appName+”.csproj”> .

El otro paso que se debe hacer es agregar a los recursos del proyecto el archivo yaml que

se encargara de la configuracion del pipeline en App Manager. Para esto debido a que App

Manager genera un repositorio espejo del repositorio original en grupos de Gitlab, lo que se hizo

fue primero subir la aplicacion a Gitlab y configurar el pipeline IC/DC directamente para esa

aplicacion con la finalidad de, a partir de este, implementar un archivo generico para todas las

aplicaciones WPF y subirlo a la carpeta de recursos del proyecto.

Para la configuracion de este archivo, lo primero que se debe hacer es elegir la imagen que se

usara. Las imagenes de Gitlab son imagenes monolıticas que corren todos los servicios necesarios

en un contenedor solo. https://docs.gitlab.com/omnibus/docker/#gitlab-docker-images.

Luego de esto, un pipeline normalmente esta dividido en tres partes (Algoritmo XXX):

BUILD: mediante scripts generamos el build de nuestra aplicacion. En el caso de una

aplicacion WPF por ejemplo se puede hacer el build.

DEPLOY: este trabajo se encarga de la distribucion de las aplicacion. Una forma de hacerlo

es usando la herramienta dplhttps://github.com/travis-ci/dpl que fue desarrollada

para CI en Gitlab.

Como se ve en el algoritmo 4.6, donde se indica donde se encuentra el proyecto a realizarse el

build. En este caso ademas de generar el build de la aplicacion, lo que se hace es crear un artefacto.

Este artefacto sirve para almacenar el build para luego poder subirlo a la nube y que de esa

manera quien necesite de este binario pueda obtenerlo. Esto se sube a algun servidor en la nube

como pueden ser los que son ofrecidos por DigitalOcean https://www.digitalocean.com/.

4.2.2. Instalador para WPF

Al final de la subseccion 4.1.2 se enumeraron los pasos a seguir para realizar una instanciacion de

un nuevo tipo de aplicaciones. Lo primero que se debe identificar es que archivos son realmente

imprescindibles para la ejecucion del nuevo tipo de aplicaciones en la computadora del usuario

final. En este caso, se pudo reconocer mediante una serie de pruebas que, tan solo con el binario

.exe generado a partir del build del proyecto, la aplicacion desarrollada por el usuario podıa

funcionar y no era necesario ningun otro archivo mas. De esta manera este problema estaba

CAPITULO 4. DISENO E IMPLEMENTACION 50

Algoritmo 4.6 Yalm necesario para la herramienta.

build:extends:- .shared windows runnersstage: buildscript:- ”cd ”${PROJECT DIR}\MicrosoftVisualStudio\\2019\\BuildTools\\MSBuild\\Current\\Bin\””- ’.\msbuild.exe ”C:\GitLab-Runner\builds\Sebey\wpfapp\FirstApp\${PROJECT NAME}\${PROJECT NAME}.csproj””/p:configuration=Release”’artifacts:name: ${CI JOB NAME} ${CI PIPELINE ID}paths:- $CI PROJECT DIR/${PROJECT NAME}/obj/releasestage: deployscript:- gem install dpl- dpl --provider=heroku --app=my-app-staging--api-key=$HEROKU STAGING API KEY- master

solucionado. Una vez reconocido esto lo que se debe hacer es lo siguiente. Cuando se genera el

build de la aplicacion en la herramienta App Manager (mediante el archivo yaml agregado al

proyecto) agregar un nuevo “Job” en el archivo yaml que consiste en generar un nuevo space con

el nombre de la aplicacion en Digital Ocean al que se le cargan los archivos necesarios para la

instalacion, en este caso el .exe.

Figura 4.12: Diagrama de clase de la instanciacion a WPF.

Como se puede ver en la figura 4.12 el otro punto a resolver era el de generar el archivo especıfica

para aplicaciones WPF en el proyecto del instalador con las tareas especıficas que se debıan

cumplir a la hora de generar un instalador para aplicaciones de este tipo como su instalacion

es sencilla ya que solo posee este ejecutable a descargar, la tarea especifica de este tipo de

aplicaciones es simplemente descargar el archivo y copiarlo en la carpeta que se creo para la

CAPITULO 4. DISENO E IMPLEMENTACION 51

aplicacion.

De esta manera podemos ver que al igual que para agregar soporte a la parte de la API de

App Manager generar soporte al proyecto del instalador fue muy sencillo. Una vez generado el

binario se debe buildear el proyecto sin anadir al build los binarios que sean de otros tipos de

aplicaciones soportadas ya que esto no tendrıa sentido. Despues de generar el archivo ejecutable

del instalador para aplicaciones WPF se subio este a un space en Digital Ocean que tenga como

nombre WPF. De esta manera, ya que en App Manager podemos reconocer que la aplicacion

conectada es del tipo WPF linkeara el boton de descarga del instalador de app manager con el

space correspondiente en Digital Ocean.

4.3. Conclusion

A lo largo del capıtulo se mostro el diseno e implementacion para generar la nueva solucion a

la herramienta App Manager para anadir soporte futuro a diferentes tipos de aplicaciones. El

diseno de dicha solucion se dividio en dos partes bien marcadas. La primera fue App Manager,

tanto la parte del back end, como la parte del cliente, y el instalador auto generado por esta

misma. Para la primera, en cuanto al back end, se logro identificar donde habıa que corroborar el

tipo de la aplicacion que se estaba conectar y anadir tanto verificaciones como implementaciones

para su soporte siempre teniendo en cuenta que estos cambios sean disenados de tal manera que

agregar soporte para un nuevo tipo de aplicaciones en un futuro sea lo mas sencillo posible. Con

respecto a la parte del cliente de App Manager los cambios fueron mınimos tan solo para agregar

cambios visuales a la herramienta, como por ejemplo a la hora de elegir el tipo de aplicacion a

agregar, que se pueda anadir los nombres de los nuevos tipos soportados facilmente. La segunda

parte fue el instalador. Lo que se hizo fue analizar las tareas comunes a los instaladores de

cualquier tipo de aplicacion a soportar y generar un soporte para agregar soporte a nuevos tipos

de aplicaciones de manera sencilla donde solo se deba implementar el trabajo especıfico para ese

tipo de aplicaciones que debe realizar el instalador.

Gracias a esta solucion se puede decir, y quedo demostrado mediante la instanciacion de aplica-

ciones WPF, que anadir soporte para cualquier tipo de aplicaciones ahora es un proceso sencillo

lo que le da a la herramienta un valor mucho mas grande y que podra ser utilizado por muchos

mas usuarios.

Capıtulo 5Resultados experimentales

En este capıtulo se desarrollara una comparacion para analizar el impacto que produce utilizar

la herramienta App Manager para la aplicacion de DevOps y para el despliegue de aplicaciones.

Se analizo y comparo la diferencia (desde el punto de vista del usuario final) entre realizar todo

este proceso de DevOps para aplicaciones WPF con la herramienta App Manager y las incorpo-

raciones realizadas durante esta trabajo final versus la implementacion manual del mencionado

proceso. Utilizando la aplicacion WPF desarrollada para probar la aplicacion de DevOps en

ambos casos, se obtuvieron resultados que fueron analizados y con los cuales se pudo realizar

un analisis de ventajas y desventajas sobre utilizar la herramienta desarrollada por sobre aplicar

DevOps sin esta.

5.1. Implementacion manual de DevOps para una aplicacion

WPF

Para la implementacion manual de DevOps se creo y almaceno un proyecto en un repositorio de

Gitlab. Para crear este pipeline lo que se hizo fue anexar al proyecto un archivo .yalm encargado

de la configuracion del pipeline que fue escrito especıficamente para este proyecto.

En la primer lınea del algoritmo 5.1 se encuentra la sentencia que indica que este pipeli-

ne se ejecutara sobre un runner de Windows https://about.gitlab.com/blog/2020/01/21/

windows-shared-runner-beta/. Estos Windows Shared Runners contienen varios paquetes de

software, como el administrador de paquetes Chocolatey https://chocolatey.org/ para Win-

dows, Visual Studio 2019 Build Tools, Microsoft .Net Framework, por nombrar algunos. Por

lo tanto, tiene un conjunto basico de herramientas para comenzar a construir aplicaciones de

Windows sin necesidad de configurar e instalar sus propios Windows Runners auto-hospedados.

Una vez definido el runner, el algoritmo 5.1 muestra los dos stages existentes, los stages estan

compuestos por trabajos, en este caso cada stage cuenta unicamente con un trabajo:

52

CAPITULO 5. RESULTADOS EXPERIMENTALES 53

Algoritmo 5.1 Configuracion del archivo .gitlab-ci.yml..shared windows runners:tags:- shared-windows- windows- windows-1809stages:- build- deploybefore script:- ”Set-Variable -Name \”time\” -Value (date -Format \”%H: %m\”)”- ”echo ${time}” - ”echo \”started by ${GITLAB USER NAME}\””- ”echo ${PROJECT DIR}”build:extends:- .shared windows runnersstage: buildscript:- ”cd \”${PROJECT DIR}\\MSBuild\\Current\\Bin\””- ’.\msbuild.exe ”C:\GitLab-Runner\builds\${PROJECT DIR}\${PROJECT NAME}\${PROJECT NAME}.csproj” ”/p:configuration=Release”’artifacts:name: ${CI JOB NAME} ${CI PIPELINE ID}paths:- $CI PROJECT DIR/${PROJECT NAME}/obj/releasestage: deployvariables:GIT DEPTH: ”1”RELEASE: ”true”dependencies:- buildbefore script:# - QUALIFIER=$(if [[ -z ”$RELEASE” ]] ; then echo ”dev”; else echo ”r”; fi)# - export VERSION=$(cat equo.go | grep ’app.Version = ”.*”’ | head -n 1 | awk -F’[><-]’ ’{print $3}’).$QUALIFIER- export VERSION=”0.0.1”- echo ”version $VERSION”script:- mkdir -p public- ”echo ${CI PROJECT DIR}”- cp -r $CI PROJECT DIR/${PROJECT NAME}/obj/release/${PROJECT NAME}.exe public- du -h -s public || true- mc config host add do https://nyc3.digitaloceanspaces.com ”$DO KEY” ”$DO SECRET” --lookup auto- mc mb -p do/$DO BUCKET- mc mirror --overwrite --remove public/relase do/$DO BUCKET/rls/- current=$(date -u +”%FT %T. %3NZ”)- echo ”current $current”- ’echo ”{\”version\”: \”${VERSION}\”, \”created\”: \”${current}\”, \”downloadInstallPath\”: \”equo\”}” > public/meta-data.json’- mc cp public/${PROJECT NAME}.exe do/$DO BUCKET/rls/after script:- ls public/${PROJECT NAME}.exeonly:- master

build: en este stage se realiza el build de la aplicacion. El objetivo es posicionarse sobre

la carpeta donde esta el archivo MsBuild que es el encargado de correr la aplicacion y

generar el ejecutable final. Se le da la ruta de donde se encuentra el proyecto a buildear y

lo hace. MsBuild es una consola de Windows capaz de reconocer y correr el archivo .csproj

a ejecutar. Una vez hecho se ejecutan los scripts necesarios para crear los artefactos. Estos

artefactos son necesarios para que una vez que el trabajo termine se pueda acceder a ese

archivo que se genero a partir del build para poder utilizarlo en otros trabajos como es el

PUBLISH dentro del stage deploy.

deploy: en el stage deploy se publican los artefactos. Este stage contiene a un trabajo lla-

mado PUBLISH encargado de publicar en un gestor de servidores como es Digital Ocean

todos los artefactos que se generaron a partir del stage build. Estos artefactos eran ne-

cesarios para correr la aplicacion conectada a App Manager. Estos scripts publican los

artefatos en un space de DigitalOcean, para luego poder ser consumido por el proyecto del

CAPITULO 5. RESULTADOS EXPERIMENTALES 54

instalador a la hora de crear el instalador para esa aplicacion en especifico. Estos spaces

son propios de la herramienta donde se almacenaran los archivos de todas las aplicaciones

que se conecten con la herramienta.

Con el pipeline IC/DC funcionando de manera correcta y ejecutandose cada vez que se fusionaba

algun cambio en la rama master otro paso importante que habıa que dar era el de crear el

instalador para la aplicacion. Investigando y buscando entre diferentes variantes como las que se

nombraron en el capıtulo 2 se tomo la decision de realizar el instalador mediante una herramienta

que provee el mismo Visual Studio. Para esto desde el tienda de aplicaciones de Visual Studio

hubo que descargar la herramienta llamada “Microsoft Installer”https://n9.cl/q2an.

Lo primero que se tuvo que hacer fue crear un nuevo proyecto en la herramienta del instalador:

“archivo-> Nuevo proyecto -> Visual Studio Installer -> Setup Proyect”. Una vez hecho esto,

aparecera una ventana con tres carpetas a completar. Una llamada “carpeta de la aplicacion”

en la que debemos buscar nuestro proyecto al que le estamos generando el instalador y anadir

todos los archivos de este proyecto con todas las dependencias que se utilizaron y demas archivos

secundarios. Otra llamada “escritorio del usuario” en la que al abrirla nos permitira crear un

acceso directo de la aplicacion a instalar. Aquı debemos marcarle al instalador donde se encuentra

el resultado final de nuestro proyecto para que cree de manera correcta el instalador. La ultima

carpeta “menu del programa del usuario” no debemos tocarla ni modificarla. De esta manera y al

compilar este proyecto tendremos el instalador de nuestra aplicacion. En la imagen 5.1 podemos

Figura 5.1: Instalador creado mediante Visual Studio Installer

ver como el instalador presenta un interfaz bastante anticuada que ademas necesita de una

participacion activa del usuario teniendo que ingresar la ruta donde desea instalar la aplicacion

CAPITULO 5. RESULTADOS EXPERIMENTALES 55

y demas. Pero como ya se explico para cumplir con el despliegue de una aplicacion ademas de

generar este instalador se debe distribuir de alguna manera. Estas maneras pueden ser mediante

la web del usuario (que de no tenerla podrıa crear una para la aplicacion), mediante las tiendas

de aplicaciones conocidos (en este caso podrıa ser el de Windows) o distribuirla personalmente

cada vez que le fuese solicitada.

5.2. Utilizacion de App Manager para una aplicacion WPF

Utilizar la herramienta App Manager para distribuir una aplicacion WPF resulta mucho mas

sencillo que hacerlo de manera manual como se mostro en la seccion 5.1. Utilizar la herramienta

simplifico el proceso en gran medida, permitiendo que cualquier desarrollador que vaya a hacer

el proceso necesario para aplicar DevOps siendo o no un conocedor de las tecnologıas y se

demostrara a continuacion.

El usuario debe crear un repositorio Git, en cualquiera de los tres gestores que se fueron nom-

brando a lo largo de este trabajo (Gitlab, BitBucket o Github) e ir cargando los cambios de su

proyecto en estos. Al mismo tiempo deberıa registrarse en la plataforma App Manager (puede

hacerlo mediante Google, Facebook o bien Github) y una vez registrado tendra acceso a la mis-

ma. Al ingresar por primera vez podra ver que ya existe una organizacion a su nombre, esta tiene

acceso a todas las aplicaciones que se carguen posteriormente, sean creadas en la organizacion

que sea, es una organizacion “Admin”. Ahora bien, el usuario puede decidir crear una aplicacion

directamente utilizando esta organizacion o bien puede crear una organizacion nueva y crear

una aplicacion adentro de esta. Sea cual sea la decision, haya creado una nueva organizacion o

no, el paso siguiente es crear una aplicacion. En la imagen 5.2 se puede observar la ventana que

Figura 5.2: Ventana creacion nueva aplicacion

se abrira cuando se selecciona la opcion de crear una nueva aplicacion, donde debemos cargar

el nombre de la misma su tipo y una descripcion a su vez debemos senalar quien es su due-

no, pre determinadamente el dueno sera la organizacion desde la que se seleccione “crear nueva

CAPITULO 5. RESULTADOS EXPERIMENTALES 56

aplicacion” pero lo podemos cambiar ya que en el deslizable “owner” apareceran todas las orga-

nizaciones a las que tiene acceso ese usuario. Una vez hecho esto el usuario debera conectar el

repositorio donde tiene el proyecto a la aplicacion que acaba de crear. En la figura 5.3 podemos

Figura 5.3: Menu de una aplicacion

ver como es el menu de una aplicacion en App Manager. Una vez aquı el usuario debe dirigirse

a la seccion “settings” donde le apareceran los tres gestores de repositorios soportados por la

herramienta y en ese momento debera seleccionar el gestor en el que se encuentre su proyecto

y luego buscar el proyecto para conectarlo con la aplicacion creada en App Manager. Una vez

seleccionado el gestor de repositorios donde se encuentra la aplicacion se debe seleccionar el

repositorio correspondiente a la misma como se ve en la imagen 5.4. Luego de conectar el re-

positorio automaticamente se empezaran a ejecutar los pipelines. Cada pipeline que termine de

manera satisfactoria generara la posibilidad de descargar el instalador y ofrecera el URL a la web

que se genera automaticamente. Si el pipeline falla, esto no ocurre. En la figura 5.5 se observar

como dos desarrolladores distintos realizaron cambios al repositorio (en diferentes ramas). Los

cambios de uno de ellos fueron exitosos mientras que los del otro no. Es por esto que la rama con

cambios exitosos ofrece la posibilidad de descargar el instalador y redirigirse a la URL mientras

que la otra rama no.

Figura 5.4: Conexion de un repositorio.

Con la aplicacion conectada con el repositorio, solo queda esperar que el pipeline que se esta

ejecutando automaticamente termine. Una vez terminado en la seccion “build history” que se

puede apreciar en la imagen 5.3 podremos observar si los trabajos del pipeline terminaron bien, y

CAPITULO 5. RESULTADOS EXPERIMENTALES 57

Figura 5.5: Build history de una aplicacion.

si esto es ası, podremos mediante un clic descargar nuestro instalador generado automaticamente.

Es necesario decir que cada vez que se fusione algun cambio al repositorio del usuario se volvera

a actualizar el pipeline y por lo tanto de la misma manera lo hara el instalador, por lo que el

usuario no debe preocuparse en ningun momento por esto. A su vez se le proporciona al usuario

una web, tambien creada automaticamente, para distribuir el instalador entre los clientes que lo

deseen.

5.3. Comparacion

Habiendo aplicado DevOps tanto de manera manual como utilizando la herramienta App Ma-

nager se puede realizar una comparacion de ambos casos para llegar a una conclusion final. A

pesar de que utilizar App Manager ofrece en su mayorıa ventajas, no se puede dejar de decir

que tambien presenta ciertas desventajas a comparacion de aplicar DevOps de manera manual,

es decir sin ninguna herramienta que automatice este proceso. Dentro de las ventajas que se

pueden reconocer a la hora de aplicar DevOps se pueden enumerar las siguientes:

No necesita de un desarrollador capacitado con conocimientos previos en DevOps para

poder aplicar esta tecnologıa a su aplicacion. Si quien esta buscando aplicar DevOps no

esta acostumbrado o no tiene lo conocimientos necesarios para hacerlo, el hecho de que

con solo conectar un repositorio a una herramienta web se automatice este proceso es de

una gran ayuda.

La herramienta ofrece un instalador nativo y que se puede distribuir a los usuarios finales.

Esto le evita al desarrollador tener que desarrollarlo el mismo a este instalador evitando

horas de desarrollo que no seran necesarias. Ademas el instalador que se esta proveyendo

posee una experiencia de usuario moderna, similar a una instalacion Andorid o Iphone.

La herramienta brinda ademas soporte para actualizaciones, cada vez que se realicen cam-

bios en el repositorio de la aplicacion y los pipelines de IC/DC terminen su proceso sa-

tisfactoriamente, el instalador automaticamente se actualizara a la esta ultima version

disponible.

No es necesario realizar mantenimiento del ciclo de DevOps ya que se encarga la herra-

mienta.

CAPITULO 5. RESULTADOS EXPERIMENTALES 58

Por otro lado, existen las desventajas que la automatizacion de procesos presenta:

Al ser un proceso automatizado resulta menos flexible a los cambios o requerimientos

especıficos que requiera un desarrollador para una aplicacion en particular.

De realizar cambios en el repositorio, si no tiene las versiones antiguas de los instaladores

previamente generados, los perderıa. La herramienta solo permite descargar el instalador

de la version actual de la herramienta. Aunque esto se podrıa solucionar o bien teniendo

los instaladores descargados o volviendo atras los cambios en el repositorio original. Es un

contratiempo a analizar.

Capıtulo 6Conclusiones

Los procesos y la forma de desarrollar, desplegar y mantener sofware y su infraestructura estan

en constante cambio, lo cual conduce inevitablemente a desafıos tecnicos y funcionales. Las

empresas requieren soluciones y procesos configurables y flexibles que les permitan desplegar

software en la nube y adaptarlos durante el ciclo de vida del mismo para asegurar las necesidades

y expectativas de sus clientes. Frente a estas necesidades, actividades como la integracion y el

despliegue continuos y la capacidad del software para su propia evolucion y re configuracion en

entornos variables son claves en la mejora y en la automatizacion de los procesos de desarrollo e

implementacion de software. El concepto de DevOps describe y desarrolla una forma de desarrollo

de software que corresponde un conjunto de tecnicas y herramientas que apoyan a la mejora

del proceso de desarrollo de software, que se apoya en la automatizacion y monitoreo de los

procesos de integracion de software. A la hora de poner en practica DevOps podemos definir

cuatro principios en este proceso como son desarrollar y probar prematuramente; iterar sobre

el desarrollo de la aplicacion; monitorear y validar software de calidad; generar ambientes de

staging y produccion.

Con la integracion de la tecnologıa de DevOps al desarrollo de aplicaciones, la forma de imple-

mentar y distribuir este tipo de aplicaciones cambio de manera drastica generando una comuni-

cacion mas fluida entre todos los equipos implicados en el desarrollo de las aplicaciones y tambien

con el usuario de estas. Tambien la automatizacion de los testeos unitarios de la aplicacion o

la automatizacion de la generacion del instalador tambien reduce el esfuerzo requerido para

configurar lanzamientos, haciendo posible que las organizaciones produzcan los lanzamientos

tan frecuentemente como se requiera. Se descubrio que los niveles mas altos de automatizacion

conducen a una garantıa de calidad mejorada. La lınea de produccion automatizada de DevOps

ayuda a garantizar que cada cambio se verifique antes de que se envıe para la entrega. Porque

cada cambio en el codigo se verifica en cada etapa del desarrollo, y los errores son descubiertos

y resueltos sobre la marcha, los productos finales tienen menos errores y el software puede ser

lanzado facilmente [15].

La existencia de una herramienta como App Manager para un desarrollador o para una empresa

59

CAPITULO 6. CONCLUSIONES 60

de desarrollo es de un potencial enorme. Teniendo en cuenta que DevOps es una nueva tecnologıa

para los equipos de desarrollo, cuestion que implica por ejemplo formacion a equipos completos y

una transicion a la adopcion de esta tecnologıa. La adopcion de DevOps puede no ser una tarea

facil o sencilla, ya que requiere que una organizacion introduzca procesos, personal y tecnologıa,

cambios e innovaciones. Como en cualquier iniciativa de mejora de procesos de software, el

camino hacia una adopcion exitosa de DevOps es unico para cada organizacion [17]. Tener una

herramienta que automatice este proceso es algo que es de gran valor. El ahorro que genera esta

herramienta en el usuario en cuanto a tiempo de aprendizaje de tecnologıas, tiempo de desarrollo,

tiempo de investigacion, sin dudas que todo esto tambien tiene un costo monetario ya que ya

sea al desarrollador hay que pagarle por estar calificado o para calificarlo, como tambien hay

que aprender a usar las plataformas y/o herramientas para poder desarrollar esta tecnologıa y

llevarla a cabo. Por todas estas razones es que App Manager es de un valor y de una utilidad

enorme. No obstante, el hecho de que solo sea aplicable a aplicaciones EUIJA era un desperdicio.

Que la herramienta solo soportase este tipo de aplicaciones hacia que el enorme potencial que

esta tiene se vea solo reducido a un grupo de aplicaciones acotando su abanico de usuarios.

Haber logrado, mediante la solucion desarrollada para este trabajo, que una herramienta tan

poderosa sea aplicable a aplicaciones de todo tipo es realmente util. Esto genera que ante el

pedido de cualquier potencial usuario que necesite de la herramienta para desplegar su aplicacion

y esta no presente soporte para ese tipo de aplicaciones se pueda cumplir con el deseo del

usuario facilmente. Con un pequeno estudio del tipo de aplicaciones al que se le quiere dar

soporte para saber por ejemplo como debe estar configurado el yalm encargado de configurar

los pipelines. Con saber como es y que partes se reconocen en la instalacion de una aplicacion

de este tipo, ya se pueda generar soporte para ese tipo de aplicaciones otorgandole al usuario

una herramienta que le simplifica el despliegue de sus aplicaciones de manera notoria. Esto se

puede ver de manera clara teniendo en cuenta lo analizado en este trabajo de tesis. Los pasos y

las tareas que se deben hacer sobre una aplicacion desde que se termina de desarrollar hasta que

se termine de desplegar son muchos y, con App Manager se ven completamente automatizados.

Previo al trabajo realizado, para dar soporte a un nuevo tipo de aplicaciones habıa que hacer

un gran esfuerzo y practicamente volver a implementar tanto la API como tambien el instalador

auto generado que se obtiene al generar el build de la aplicacion. Hoy en dıa con anadir cierto

comportamiento especifico al instalador y anadir a la API de App Manager dos lineas de codigo

(para agregar el nombre del nuevo tipo a las estructuras) generarıamos soporte para este nuevo

tipo de aplicaciones.

No se debe dejar a un lado el hecho de que ahora, ademas de soportar aplicaciones de todo

tipo, App Manager extendio la caracterıstica de auto-generar un instalador para cada tipo de

aplicacion soportada. Esto, teniendo en cuenta que la distribucion de la aplicacion de escritorio

es parte fundamental del ciclo de vida de la misma es algo muy valioso. Se puede resaltar ademas

que se trata de un instalador compacto ya que el usuario sepa que tiene soporte para todo tipo

de aplicaciones no lo hace pesado ni grande al ejecutable ya que cada tipo de aplicacion posee un

ejecutable diferente y unico para cada tipo de aplicaciones (a menos que dos tipos de aplicaciones

CAPITULO 6. CONCLUSIONES 61

diferentes necesiten de los mismos binarios y sigan el mismo ciclo de instalacion) lo que hace mas

portable y facil de distribuir. Lo mismo pasa a la hora de obtener los recursos para la instalacion

en sı misma, como son los binarios a instalar, y todas las tareas a solicitar mediante protocolos

http que las realiza CEF 4.1.2

6.1. Trabajos Futuros

Teniendo en cuenta el poder que presenta la herramienta App Manager y lo grande que es el

abanico de posibilidades para anadir funcionalidades a la misma o, como se hizo en este trabajo,

mejorar alguna de las ya existentes se presentaran algunos posibles trabajos que se pudiesen

llevar a cabo. La mayorıa de estos surgieron como ideas durante el desarrollo de este trabajo.

Para empezar seria de gran valor para la herramienta generar soporte para el analisis de esta-

dısticas de las aplicaciones. Este punto se encuentra aun sin desarrollar pero serıa de gran valor

que App Manager, ademas de desplegar tu aplicacion, sea capaz de generar un analisis en base

a diferentes metricas que podrıan ser configurables por el usuario, eligiendo desde un abanico de

posibilidades. De esta manera el usuario de App Manager podrıa identificar parametros como,

cuantas descargas de su aplicacion se producen, perfiles de la gente que descarga su aplicacion,

el uso que se le va a dar a dicha aplicacion, la ubicacion geografica de los usuarios que realizan

la descarga. Tambien se podrıa analizar que funciones de la aplicacion son las que mas se usan,

entre muchos mas analisis que se pueden hacer.

Un gran atributo que se le podrıa agregar a la herramienta, pensando que quienes le daran

uso seran desarrolladores mientras desarrollan su aplicacion, serıa tener una tabla de tareas a

realizar a modo de organizador de tareas sobre la aplicacion. Cada vez que se descubre una falla

en la aplicacion o se desea crear una nueva funcionalidad o tarea, tener la posibilidad de anadir

un ticket con esa tarea. Este ticket se le podrıa asignar a un integrante de la organizacion se

le podrıa poner un plazo de tiempo para su realizacion, se tendrıa un nombre un numero de

tracking y una descripcion de lo que se pretende realizar, donde se podrıa dar una especie de

chat para ir presentando y resolviendo dudas en base a la tarea.

Como suplemento a la herramienta App Manager, otra herramienta que se podrıa generar, seria

una tienda de aplicaciones. Cada organizacion tendrıa la posibilidad de decidir si desea o no

que su aplicacion se agregue a esta tienda para su futura distribucion. Esta tienda contarıa

con las aplicaciones de los usuarios pudiendolas encontrar ya sea por la organizacion que las

creo, por el tipo de aplicacion que es (si es una aplicacion Equo o una aplicacion java, etc).

Se podrıan monetizar o entregarlas de manera gratuita, se le podrıa anadir la posibilidad de

adjuntar al perfil de la aplicacion un tutorial del funcionamiento de la misma, y algun tipo de

soporte tecnico, entre otras herramientas con las que podrıa contar esta tienda.

Otra gran extension que se le podrıa agregar a la aplicacion App Manager podrıa ser el firmado

de licencias para las aplicaciones conectadas con la herramienta. Las licencias de software son

un conjunto de permisos que un desarrollador da para la distribucion, uso y/o modificacion de

CAPITULO 6. CONCLUSIONES 62

la aplicacion que desarrollo. En esta licencia puede indicar tambien los plazos de duracion, el

territorio donde se aplica, etc. Existen varios tipos de licencias tanto para proteger como para

vender una aplicacion. Las mas comunes son:

Licencias de software Shareware: Corresponden a un tipo de distribucion de aplicaciones

que consiste en liberar gratuitamente una version con funcionamiento limitado. Esa limi-

tacion puede ser temporal (despues de determinada cantidad de dıas deja de operar), por

funciones (desde el comienzo, o a partir de determinado momento, hay funciones que el

programa deja de realizar) o una combinacion de las mencionadas (el programa empieza

con todas sus funciones y deja de realizar algunas al cabo de cierto tiempo).

Licencias de software Freeware: son licencias de software que permiten obtener, instalar

y/o usar gratuitamente un programa de computador. No es necesario que el usuario se

registre, se suscriba o compre una licencia. La gran diferencia entre el freeware y el codigo

abierto (“open source”) es que el primero es cerrado, es decir, el usuario solo tiene acceso

al codigo objeto del programa, no al codigo fuente.

Licencias de software libre: una aplicacion de software libre suele licenciarse bajo deter-

minadas licencias creadas principalmente por organizaciones, como la licencia General

Public License (GNU GPL) https://www.gnu.org/, creada y promovida por la Free Soft-

ware Foundation https://www.fsf.org/, la licencia Apache https://www.apache.org/

licenses/LICENSE-2.0, la licencia Mozilla Public License https://www.mozilla.org/

en-US/MPL/, creada y promovida por la Mozilla Foundation y usada en su producto mas

conocido, el navegador web Mozilla Firefox, entre otras.

Como se dijo anteriormente ademas de estas hay mas licencias y el abanico es muy amplio,

por ejemplo licencias que exigen los sistemas operativos para poder vender tu aplicacion en

sus respectivas tiendas. Es por esto, que serıa una gran herramienta automatizar el firmado de

aplicaciones mediante App Manager.

Bibliografıa

[1] Akshaya, H., Vidya, J., and Veena, K. A basic introduction to devops tools. Interna-

tional Journal of Computer Science & Information Technologies 6, 3 (2015), 05–06.

[2] Bernstein, D. Containers and cloud: From lxc to docker to kubernetes. IEEE Cloud

Computing 1, 3 (2014), 81–84.

[3] Blischak, J. D., Davenport, E. R., and Wilson, G. A quick introduction to version

control with git and github. PLoS computational biology 12, 1 (2016).

[4] Chen, L. Continuous delivery: Huge benefits, but challenges too. IEEE Software 32, 2

(2015), 50–54.

[5] De, B. API documentation. In API Management. Springer, 2017, pp. 59–80.

[6] Duvall, P. M., Matyas, S., and Glover, A. Continuous integration: improving soft-

ware quality and reducing risk. Pearson Education, 2007.

[7] Figueroa, R. G., Solıs, C., and Cabrera, A. Metodologıas tradicionales vs. Meto-

dologıas Agiles. Universidad Tecnica Particular de Loja, Escuela de Ciencias en Compu-

tacion.[Loja, Ecuador] (2008).

[8] Freeman, E. DevOps For Dummies. John Wiley & Sons, 2019.

[9] Fresneda, M. D., and Mendoza, E. Trastorno especıfico del lenguaje: Concepto, clasi-

ficaciones y criterios de identificacion. Revista de Neurologıa 41, 1 (2005), 51–56.

[10] Hamill, P. Unit test frameworks: tools for high-quality software development. .O’Reilly

Media, Inc.”, 2004.

[11] Linnenkugel, U., and Mullerburg, M. Test data selection criteria for (software) inte-

gration testing. In Systems Integration’90. Proceedings of the First International Conference

on Systems Integration (1990), IEEE, pp. 709–717.

[12] Mollevik, I., Olsson, S., Vikdahl, M., Weijand, S., and Westin, J. Seminar: The

rust programming language.

63

BIBLIOGRAFIA 64

[13] Oluwatosin, H. S. Client-server model. IOSRJ Comput. Eng 16, 1 (2014), 2278–8727.

[14] Ramirez, N. WiX 3.6-A Developer’s Guide to Windows Installer XML. Packt Publishing

Ltd, 2012.

[15] Riungu-Kalliosaari, L., Makinen, S., Lwakatare, L. E., Tiihonen, J., and Man-

nisto, T. Devops adoption benefits and challenges in practice: a case study. In Inter-

national Conference on Product-Focused Software Process Improvement (2016), Springer,

pp. 590–597.

[16] Sharma, S., and Coyne, B. Devops for dummies. Limited IBM Editionabook (2013).

[17] Smeds, J., Nybom, K., and Porres, I. Devops: a definition and perceived adoption

impediments. In International Conference on Agile Software Development (2015), Springer,

pp. 166–177.

[18] Spinellis, D. Package management systems. IEEE software 29, 2 (2012), 84–86.

[19] Swartout, P. Continuous delivery and DevOps: A quickstart guide. Packt Publishing

Ltd, 2012.

[20] Van Rousselt, R. Incoming webhooks. In Pro Microsoft Teams Development. Springer,

2021, pp. 243–274.

[21] Verona, J. Practical DevOps. Packt Publishing Ltd, 2016.

[22] Yang, G. Life cycle reliability engineering. John Wiley & Sons, 2007.

[23] Zhu, L., Bass, L., and Champlin-Scharff, G. Devops and its practices. IEEE Software

33, 3 (2016), 32–34.