Post on 15-Jul-2022
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.