Herramientas Open Source para La Integración Continua PDF

Universidad Mayor de “San Simón”
Facultad de Ciencias y Tecnología
Herramientas Open Source para la Integración

Continua, en Proyectos de Desarrollo de Software
Elaborado por: Henry Bustamante Cruz

Carrera: Ingeniería de Sistemas
Tutor: MSc. Richard Félix López Fulguera
Fecha: Octubre de 2018
Cochabamba – Bolivia
Herramientas Open Source para la Integración Continua, en Proyectos de Desarrollo de Software – Henry Bustamante C.
Esta monografia esta dedicada a toda mi

familia, por todo el apoyo que siempre me
han brindado a mi padre Elio y mama Rosa,
tambien a mis hermanos, y en especial a mi
hijo Elias Augusto, y mi esposa Vanessa que
siempre hacen que la inspiración fluya en mi
carrera y mi vida.
ii
Tabla de Contenido
Resumen 5
Introducción 6
1 Generalidades 7
1.1 Antecedentes Generales 7
1.2 Antecedentes Específicos 9
2 Metodología 10
3 Herramientas de código abierto para la integración continua 10
4 Herramientas Open Source mas conocidas y usadas de Integracion Continua 11
4.1 Jenkins 11
4.2 GoCD 13
3.2.1. Conceptos Importantes GoCD 15
4.3 Travis CI 22
4.3.1 Job en Travis CI 24
5 Herramientas complementarias al proceso de integración continua 26
5.1 Servidor Linux 26
5.2 SonarQube 27
5.3 Nexus repository 29
5.4 Git 31
6 Conclusiones 34
7 Bibliografía 36
TABLA DE CUADROS, GRAFICOS Y FIGURAS

Descripción Pág.
Figura 1 – Relación de Integración, Entrega y Despliegue Continua 7
Figura 2 – Característica de Integración Continua 8
Figura 3 – Integracion Continua con Jenkins 13
Figura 4 – Sistema de integración y entrega continua 15
Figura 5 – Servidor y Agentes 16
Figura 6 – Pipelines y Materials 17
Figura 7 – Stages, Jobs and Taks 18
Figura 8 – Representación Pipeline 19
Figura 9 – Nombrar nuevo Pipeline 20
Figura 10 – Seleccionar Material 20
Figura 11 – Definición del Job 21
Figura 12 – Artifact 22
Figura 13 – Lenguajes soportados por Travis CI 23
Figura 14 – Arquitectura Travis CI 24
Figura 15 – Archivo .travis.yml 25
Figura 16 – UI Travis CI 25
Figura 17 – Jenkins, SonarQube o Nexus en un Servidor Ubuntu 27
Figura 18 – Lenguajes soportados por SonarQube 29
Figura 19 - Resumen de resultado después de un análisis 29
Figura 20 - dependencias maven sin nexus 30
Figura 21 – Dependencias maven usando nexus repository 31
Figura 22 – Integracion git con Herramientas de IC 33

4
Resumen
El presente documento, se explica sobre las herramientas open source disponibles hoy
en día, para la integración continua en proyectos de desarrollo de software, donde se las
mencionan y describen las características de cada una de ellas para poder conocerlas y
tener un vistazo de ellas con respecto a otras.
5
Introducción
Actualmente existen varias herramientas para la integración continua en proyectos de

desarrollo de software, donde entre toda esta variedad, podemos encontrar herramientas
que se adecuan más a nuestro tipo de proyecto, esto podemos determinarlo de acuerdo
al conocimiento de la herramienta o al lenguaje en el que esta implementado nuestro
proyecto.
Además de que existen herramientas de integración de pago, también las hay las que
son open source (código abierto y que no tienen costo alguno), en el presente documento
nos enfocaremos más en las herramientas de open source, también cabe destacar, que
existen herramientas que tienen un doble propósito; el de integración continua y entrega
continua, que detallaremos más adelante.
Lo que se pretende alcanzar con esta monografía, es explicar un poco los conocimientos
adquiridos en el curso del diplomado, sobre las herramientas open source que
actualmente existen. apoyados de una estrategia o plan para llevar a cabo la aplicación
de estos conocimientos adquiridos en esta investigación.
6
1 Generalidades
La motivación para la elección de este tema de monografía (como parte final del
Diplomado Experto en Desarrollo de Aplicaciones Empresariales), vienen determinadas
por la inquietud profesional en el campo de la ingeniería y el mundo del desarrollo de
software en general, y también lo interesante que fue aprender una pequeña parte de lo
que es y conlleva la integración continua en proyectos de desarrollo de software.
También comentaremos sobre algunas herramientas open source que podríamos usar
para nuestros proyectos de desarrollo. Lo que nos permitirá automatizar las tareas que
son repetitivas (compilación, ejecución de pruebas, construcción, despliegue,
documentación), en proyectos de desarrollo de software.
1.1 Antecedentes Generales
¿Qué es integración continua?
Según Martin Fowler la integración continua se define como una:
“Práctica de desarrollo de software donde los miembros del equipo integran su trabajo
frecuentemente, al menos una vez al día. Cada integración se verifica con un build
automático (que incluye la ejecución de pruebas) para detectar errores de integración tan
pronto como sea posible” [1].
Figura 1. Relación de Integración, Entrega y Despliegue Continua.
Fuente: Shahin, Mojtaba & Ali Babar, Muhammad & Zhu, Liming. (2017). Continuous
Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges
and Practices. Recuperado de: https://ieeexplore.ieee.org/document/7884954
7
Tambien podriamos decir que la integración continua es una de las muchas prácticas o
enfoques que existen en proyectos de desarrollo de software agil en la actualidad, donde
la integracion continua a adoptado metodologías ágiles, para poder estar al nivel del
desarrollo agil hoy en dia. Donde cualquier cambio (o mejora) en el software se integra
rápidamente con el software destinado a producción, un pequeño ejemplo sería el
siguiente:
Donde tenemos una pequeña representación de integración continua, y cada

desarrollador (developer) realiza los commits de manera atómica al control de versiones
(Git por ejemplo), luego se ejecutan los Jobs en el servidor de integración, para compilar
el código, pasando luego por los test unitarios y como paso previo al build la ejecución
de los test de integración, una vez concluidos estos pasos se genera el build.
Figura 2. Característica de Integración Continua.

fuente: Paul M.Duvall with Steve M. A. Glover. (2007). Continuous integration (Improving
Software Quality and Reducing Risk) p 15.
8
1.2 Antecedentes Específicos
Hoy en día aun muchas empresas no han adoptado el enfoque de integración continua
debido a la costumbre de algo tradicional y muy conocido por muchos (enfoque ágil) pero
el desarrollo ágil no es suficiente para poder avanzar en proyectos grandes donde el
tiempo de desarrollo , testeo y entrega a producción tienen largos tiempos entre ellos, es
ahí donde la integración de todo se vuelve un caos total debido a muchos inconvenientes
que puedan ser encontrados y podríamos decir que hasta podrían presentarse Issues
críticos en esa integración y el costo que esta pueda tener en tiempo y esfuerzo podrían
ser significativamente considerables.
Es por eso que en muchas de las empresas de desarrollo de software que adoptan
metodologías ágiles, en las cuales la entrega continua y despliegue continuo cabe como
anillo al dedo, debido a lo que la integración/entrega continua representa, es una forma
de decir que lo que se implementa es de manera ágil y los cambios están sometidos a
testeos automatizados apenas sean terminados y que no se toma mucho tiempo en la
espera de que estos sean testeados por equipos de QA (Quality Assurance).
¿Que beneficios tiene la integracion Continua?
Algunos beneficios o ventajas que nos propone la integración continua son las siguientes:
• Si no sigue un enfoque continuo, tendrá períodos más largos entre integraciones.

• Aumenta la visibilidad permitiendo una mayor comunicación, con esto nos
referimos a que si tienes un proceso y un entorno de integración continua, tienes un
proceso automático de integración, donde este proceso esta compuesto por; compilación,
testeo, control de calidad, etc. Y como este proceso se activa frecuentemente significa
que podemos saber el estado del proyecto frecuentemente.
• Paul M.Duvall with Steve M. A. Glover (2007) sostienen se reducen riesgos, debido
a que los bugs se encuentran a tiempo para ser corregidos sin tener que arriesgar algún
sprint en cuestión [2].
• Reduce el proceso repetitivo manual, lo que significa que libera de alguna manera
al equipo de DevOps de tareas monotonas y permite ser mas productivo al equipo de
desarrollo.
9
• Construye una base sólida, en el proyecto realizado.

• El tiempo de espera cortos, que permite ver si el código implementado presenta
algún defecto.
• Reduce los problemas de integración, permitiendo hacer entregas más rápidas.
Logra mayor auto-confianza y seguridad en el equipo de desarrollo, Jez Humble & David
Farley (2010) sostiene que la experiencia demuestra que un equipo que utiliza integración
continua logra una mayor confianza interna, al estar comprobando constantemente el
estado del desarrollo.Y no es solamente la confianza en el equipo, es también del entorno
(usuarios, gestores, etc.) Un equipo de desarrollo de software que se siente seguro es un
equipo más motivado y más productivo. [3]
2 Metodología
La metodología guía para esta monografía fueron las siguientes:
• Método bibliográfico, por la revisión de documentos, artículos y blogs referentes al

tema de estudio, y además la compilación del contenido importante sobre el tema
de estudio, Integración continua.
• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

documentos relacionados al tema de estudio y la experiencia de las clases del
modulo de Gestion de Entregas y configuración.
3 Herramientas de código abierto para la integración continua
Cuando hablamos de integración continua, muchas veces lo primero que se nos viene a
la mente es Jenkins y Git, pero a continuación veremos que existen otras herramientas
para la integración continua y entrega continua:
- Jenkins (basada en el proyecto Hudson).
- Buildbot (Desarrollado en Python, basada en el framework Twisted).
- Travis CI (es probablemente uno de los servidores CI más sencillos para empezar).
- Strider (Está escrito en Node.JS y JavaScript, y utiliza mongoDB como
almacenamiento).
- Go (fue creado y luego liberado por ThoughtWorks).
10
- Integrity (Construido sobre la base de Ruby).
A continuación, hablaremos de Jenkins y Go CD, para luego hacer una pequeña

comparativa entre ellos.
4 Herramientas Open Source mas conocidas y usadas de Integracion Continua
4.1 Jenkins
Jenkins hace énfasis en la integración continua, John Ferguson Smart (2011) sostiene
que una buena infraestructura de CI puede agilizar el proceso de desarrollo a través de
para el desarrollo, ayude a detectar y corregir errores más rápidamente, proporcione un
útil panel de proyectos para desarrolladores y no desarrolladores y, en última instancia,
ayude a los equipos
Entregar más valor comercial real al usuario final. Todo equipo de desarrollo profesional,
no importa cuán pequeño sea, debe practicar la IC.[4]
John Ferguson Smart (2011) define Jenkins, originalmente llamado Hudson, es una
herramienta de integración continua de código abierto escrita en Java. Con una
participación dominante, Jenkins es utilizado por equipos de todos los tamaños, para
proyectos en una amplia variedad de lenguajes y tecnologías, incluyendo .NET, Ruby,
Groovy, Grails PHP y más, así como Java. Entonces, ¿qué ha hecho de Jenkins un éxito?
¿Y por qué usar Jenkins para su infraestructura de CI?
En primer lugar, Jenkins es fácil de usar. La interfaz de usuario es simple, intuitiva y
visualmente atractiva, y Jenkins en general tiene una curva de aprendizaje muy baja.
Sin embargo, Jenkins no sacrifica el poder ni la extensibilidad: también es
extremadamente flexible y fácil de adaptar a sus propios propósitos. Existen cientos de
complementos que están disponibles, y cada semana salen más. Estos complementos
cubren todo, desde sistemas de control de versiones, herramientas de compilación,
métricas de calidad de código, notificador de compilación, integración con sistemas
externos, personalización de UI, juegos y mucho más. Y su instalación es rápida y fácil.[5]
Jenkins puede instalarse a través de paquetes de sistema nativos, Docker, o incluso
ejecutarse de manera independiente en cualquier máquina con un Java Runtime
Environment (JRE) instalado.
Algunas características mas sobresalientes de Jenkins se describe a continuación:
11
o Herramienta de integración continua.

o Identifica las distintas tareas en (Jobs).
o Mantiene un histórico de la ejecución y el resultado de los mismos.
o Los (Jobs) son altamente configurables, permitiendo lanzar desde compilaciones
de aplicaciones java, android, iOs, hasta deploys contra servidores de aplicaciones.
o Notifica a los afectados en caso de eventualidades.
o Monitorización de resultados.
o Enorme cantidad de plugins disponible.
Jenkins es una herramienta muy útil en integración continua de software, debido a que
posee una gran variedad de funcionalidades (especialmente para el área DevOps),
como las que se mencionan en el párrafo anterior, y también es fácil e intuitivo para
poder aprender a cómo usarlo, además de la documentación misma de Jenkins que nos
puede servir mucho para nuestros primeros pasos con esta herramienta.
Algunas de las opciones que podríamos explotar más de Jenkins serían los Jobs, que en
lo personal creo que esto nos ahorra bastante tiempo cuando tenemos tareas
automatizadas, en el sentido de que solo debemos configurarlo e integrarlo con nuestro
proyecto para que se lleven a cabo dichas tareas de manera que estas se conviertan en
algo automático y repetitivo, liberando a DevOps de tareas y permitiendo hacer mas
productivo al equipo de desarrollo.
12
BUILD
Paso 3: Archivar los

Builds resultantes
Paso 4: Disparar los test
Paso 2: Ejecutar el
de integración
script shell
Paso 1: Ejecutar la Paso 5:

compilación del Monitorear la
código ejecución de las
tareas
Paso 6: Tener la
Paso 7: Envio de opción de detener
notificación de el build en caso de
éxito o de falla en haber fallado
la generación de
los builds
Figura 3. Integracion Continua con Jenkins.
Fuente: Elaboracion propia.
por ejemplo:
Para generar un build de un proyecto “X” se siguen algunos pasos previos, que seria
configurar nuestro servidor de integración (Jenkins en este caso), de tal manera que
cuando subamos cambios (cambio de código, que podría ser algún feature, fix o mejora
del código, como refactorización), se active un Job encargado de procesar el commit
realizado en nuestro servidor de versiones (Git por ejemplo), que pueda capturar el
commit y ademas que pueda generar el build del proyecto.
4.2 GoCD
13
Go CD (Continuos Delivery), que en español seria Entrega continua, es otra herramienta

que podríamos usar para la integración continua en nuestros proyectos, esta herramienta
fue creada por la empresa Thougtworks, que es la empresa donde Trabaja Martin Fowler
(es un Diseñador de software que trabaja en una de las empresas importantes de Entrega
de software, además de haber escrito algunos libros de Refactorización y Patrones de la
arquitectura de aplicaciones empresariales) [6].
Esta Herramienta era de pago hasta febrero de 2014, que fue cuando se liberó el código
a una comunidad open source. aunque hoy en día Thougtworks aún sigue colaborando
y además ofrece algunos servicios plus que tiene costo como (soporte personalizado,
consultoría, etc.).
En general Go fue diseñada y pensada como una herramienta de entrega y despliegue
continuo, y no solo de integración continua.
A continuación podemos ver un pequeño grafico sacado de la documentación de la
pagina oficial de GoCD.
Este grafico representa a grandes rasgos el proceso de integración y despliegue

continuo, divididos ambos en dos bloques, donde el primero Build representa una versión
del proyecto en cuestión, donde recibe entradas que son código fuente que son
procesadas por los Jobs, en las etapas correspondientes y finalmente todos estos forman
el paquete seguido del proceso de integración y testeo debidamente ejecutados, pasan
a un entorno activo del sistema (Proyecto en cuestión) denominado en la grafica como
ENV & APP CONFIG este ultimo sucede en el proceso de Test and Release.
14
Figura 4. Sistema de integración y entrega continua.

Fuente: Documentación GoCD, recuperado de: https://docs.gocd.org/current/).
3.2.1. Conceptos Importantes GoCD

a) Server y Agents:
Donde podríamos traducirlo a (Agentes y Servidor), En el ecosistema de GoCD, el
servidor es el que controla todo. Proporciona la interfaz de usuario a los usuarios del
sistema y proporciona trabajo para los agentes. Los agentes son los que realizan
cualquier trabajo (ejecutar comandos, implementaciones, etc.) que configuren los
usuarios o administradores del sistema.
El servidor no realiza ningún "trabajo" especificado por el usuario por su cuenta. No
ejecutará ningún comando ni realizará implementaciones. Esa es la razón por la que
necesita un servidor GoCD y al menos un agente de GoCD instalado antes de continuar.
15
Figura 5. Servidor y Agentes.

Fuente: getting-started/Concept 1: Server and Agents, recuperado de:
https://www.gocd.org/getting-started/part-1/
b) Pipeline y Materials:
Pipeline, una representación del flujo de trabajo o una parte de un flujo de trabajo. Por
ejemplo, si está intentando ejecutar pruebas automáticamente, crear un instalador y luego
implementar una aplicación en un entorno de prueba, esos pasos se pueden modelar
como una canalización. GoCD proporciona diferentes construcciones de modelado
dentro de una tubería, como etapas, trabajos y tareas. Los veremos en más detalle
pronto. Para el propósito de esta parte de la guía, debe saber que se puede configurar
una canalización para ejecutar un comando o un conjunto de comandos.
Otro concepto igualmente importante es el de un material. Un material es una causa para

que un pipeline se "dispare" o para comenzar a hacer lo que está configurado para hacer.
Normalmente, un material es un repositorio de control de origen (como Git, Subversion,
etc.) y cualquier nuevo commit en el repositorio es una causa para que el pipeline se
dispare. Un pipeline debe tener al menos un material y puede tener tantos materials de
los diferentes tipos que desee.[7]
16
Figura 6. Pipelines y Materials.
Fuente: getting-started/Concept 2 Pipelines and Materials, recuperado de:

https://www.gocd.org/getting-started/part-1/
c) Stages, Jobs y Tasks

Task, una (tarea) suele ser un comando que está configurado para ejecutarse como parte
del trabajo en el que se encuentra. No todas las tareas deben ser simples, ya que las
tareas pueden ser complementos. GoCD tiene tareas Ant, NAnt y Rake como tareas
integradas, pero tiene muchos más complementos opcionales que se pueden instalar.
Job, es una colección secuencial de tareas. Cada tarea en un trabajo se ejecuta una
después de la otra, y en su configuración predeterminada, si una tarea falla, ninguna de
las tareas siguientes a esa se ejecuta. Entonces se considera que el trabajo ha "fallado".
El aspecto más importante de un trabajo es que un solo agente tiene que recoger y
terminar un trabajo. Por lo tanto, puede tener la garantía de que todas las tareas de un
trabajo se ejecutan en el mismo agente.
Stage, una (etapa) es una colección de Jobs, pero los Jobs no son secuenciales. Se
pueden recoger en cualquier orden y, por lo tanto, tienen que ser independientes entre
sí. Esta distinción crucial entre cómo un Job se compone de sus Tasks (secuenciales) y
cómo una etapa se compone de sus Jobs (no secuenciales) es lo que proporciona la
paralelización incorporada en GoCD. Dado que los Jobs en una etapa, son
independientes entre sí, todos se iniciarán juntos, cuando comienza una etapa.
17
Suponiendo que haya suficientes agentes iniciados y no ocupados, entonces todos los
Jobs en una etapa pueden ejecutarse en un agente diferente al mismo tiempo, lo que
posiblemente acelere mucho su compilación.
Figura 7. Stages, Jobs and Taks.

Fuente: getting-started/Concept 4: Stages, jobs and tasks
, recuperado de: https://www.gocd.org/getting-started/part-1/
Go CD hace énfasis en el uso de los pipelines, al igual que otras herramientas de

integración continua, la cual se puede describir de la siguiente manera:
Un pipeline consta de múltiples etapas, donde cada una de las cuales se ejecutará en
orden. Por ejemplo, si una de ellas falla, significa que las demás y no se iniciarán, a esto
lo denomina un pipeline fallido.
18
En el siguiente grafico veremos un poco de los que los pipelines hacen hablando en este
caso particular de la herramienta Go CD, para tal caso se tomará un ejemplo de un
pipeline con 3 etapas,
Donde la primera contiene dos Jobs, la segunda tres y la tercera solo un Job. Como se
mencionaba anteriormente decíamos que, si en un pipeline hay alguna etapa fallida, todo
el pipeline es fallido y deja de ejecutarse si en caso existieran más pipelines pendientes
de ejecución.
Figura 8. Representación Pipeline.

Fuente: GoCD Documentation/Concepts in GoCD:
Pipeline, recuperado de: https://docs.gocd.org/current/introduction/concepts_in_go.html
Donde para configurarlo se siguen los siguientes 3 pasos según la documentación de Go

CD.
Paso 1: hacemos click en botón Add new Pipeline, luego nos mostrará los tabs
necesarios para configurar nuestro pipeline, donde ponemos el nombre de nuestro
pipeline y el grupo al que pertenecerá este.
19
Figura 9. Nombrar nuevo Pipeline.

Fuente: getting-started: Creating a new Pipeline (step1)
Paso 2: Tenemos disponible un tab llamado Material que es donde llenamos la

información de los recursos que necesita para procesar el Job, en este caso en el campo
type ponemos que tipo de repositorio estamos usando (en el ejemplo Git) que en
resumen seria el sistema de control de versiones de nuestro proyecto, luego llenamos la
rama de la cual leeremos el código o de la cual escucharemos los cambios para que sean
procesados por el Job (rama master en el ejemplo).
Figura 10. Seleccionar Material.

20
Fuente: getting-started: Creating a new Pipeline (step 2)

Actualmente Go CD soporta los siguientes sistemas de control de versiones o solo control
de versiones:
• Subversion
• Mercurial
• Git
• Team Foundation Server
• Perforce
Paso 3: En este punto debemos configurar el Job que estará asociada a la etapa que
definamos en este tab, donde podemos tener más de un Job o Task dentro esta etapa
como habíamos mencionado anteriormente.
Para tal propósito llenamos el nombre de la etapa, seguida del modo en que este
Jos/tarea se activara, para este ejemplo elegimos cuando se haga un commit satisfactorio
en nuestro repositorio, luego definimos el nombre de nuestro Job y el tipo de tarea que
este ejecutara y con eso sería suficiente para poder crearnos nuestro pipeline en Go CD.
Figura 11. Definición del Job.
21
Fuente: getting-started: Creating a new Pipeline (step 3)

Cada Job en Go puede publicar Artifacts (artefactos), que son archivos o directorios,
que se publican y se ponen a disposición del usuario, una representación de artefactos
se muestra a continuación.
Figura 12. Artifact.

Fuente: GoCD Documentation/Concepts in GoCD:
Artifacts, recuperado de: https://docs.gocd.org/current/introduction/concepts_in_go.html
4.3 Travis CI
Como una plataforma de integración continua, Travis CI se basa en su proceso de

desarrollo donde crea y prueba automáticamente los cambios de código, proporcionando
información inmediata sobre el éxito del cambio. Travis CI también puede administrar
otros procesos del desarrollo administrativo, como los despliegues de nuestros proyectos
en algún entorno especifico y también provee notificaciones, los cual parece bien para
mantenernos al tanto de lo ocurrido.
Algunas de las empresas Importantes que confian en la Herramienta Travis CI son:
Zendesk, Engine Yard, HEROKU, BitTorrent y MOZ.
22
Travis Tambien prove un considerable numero de lenguajes soportados para poder

trabajar en un entorno de integracion continua.
Figura 13. Lenguajes soportados por Travis CI.

Fuente: Travis CI – Getting Started, recuperado de: https://docs.travis-ci.com/).
Christopher Weyand, Jonas Chronik, Lennard Wolf, Steffen Kötte, Konstantin Haase, Tim
Felgentreff, Jens Lincke y Robert Hirschfeld (2017), afirman que Travis CI es un servicio
de integración continua alojado y estructurado como una arquitectura de microservicio.
Los componentes modulares, aunque mínimamente acoplados, son subsistemas
complejos corriendo en la nube, debido a la utilización de las librerías y software
entrelazadas y mecanismos sofisticados de programación, una comprensión exhaustiva
de la construcción del sistema no es trivial. Proporcionar la base para una evaluación de
la modularidad, extensibilidad y escalabilidad de la arquitectura.
Aunque Travis CI ofrece funcionalidad e implementación continuas completamente
funcionales para muchos lenguajes de programación y plataformas, todavía carece de
23
algunas características comunes a otras herramientas de CI. En particular, falta una

forma de hacer frente a las dependencias, así como una página web que presenta
información útil sobre el proyecto de software.[8]
Figura 14. Arquitectura Travis CI.

Fuente: Weyand Christopher, Chronik Jonas, Wolf Lennard, Kötte Steffen, Haase Konstantin,
Felgentreff Tim, Lincke Jens and Hirschfeld Robert (2017). Improving Hosted Continuous
Integration Services. Potsdam-Alemania, (p. 10)
4.3.1 Job en Travis CI
Los Jobs en Travis CI al igual que en Jenkins y GoCD tiene la función de ejecutar o llevar a cabo
tareas configuradas previamente, pero en este caso la ejecución de los Jobs y demás tareas que
queramos ejecutarlos, para la integración continua, este se lo hace mediante un archivo
.travis.yml en cual definimos las tareas que queramos configurar y ejecutar, por ejemplo para
crear nuestro build.
Si no tenemos presente este archivo en nuestro proyecto, por ejemplo en nuestro repositorio
GitHub entonces cuando estemos en el UI de travis podremos ver que nada pasa mientras
hagamos varios commits.
24
Un pequeño ejemplo del archivo seria el siguiente:
Figura 15. Archivo .travis.yml.

Fuente: Elaboración propia.
Revisando un poco la herramienta UI, esta no presenta una variedad de opciones a nivel de UI,
a comparación con GoCD y Jenkins los cuales te facilitan con una gran variedad de opciones y
fácil use bajo un seguimiento de la documentación, Pero con Travis CI no es el caso, almenos en
la versión gratuita.
Figura 16. UI Travis CI.

Fuente: Elaboración propia
25
5 Herramientas complementarias al proceso de integración continua
Las Herramientas/recursos que se detallan a continuación son muy útiles y se

complementan bien con las herramientas previamente descritas antes, y entre las mas
destacadas se eligieron las siguientes.
5.1 Servidor Linux

¿Que es Linux?
LINUX, es un sistema operativo que consiste en varios programas fundamentales que
necesita el ordenador para poder comunicar y recibir instrucciones de los usuarios; tales
como leer y escribir datos en el disco duro, cintas, e impresoras; controlar el uso de la
memoria; y ejecutar otros programas. La parte más importante de un sistema operativo
es el núcleo. En un sistema GNU/Linux, Linux es el núcleo. El resto del sistema consiste
en otros programas, muchos de los cuales fueron escritos por o para el proyecto GNU.
Dado que el núcleo de Linux en sí mismo no forma un sistema operativo funcional,
preferimos utilizar el término “GNU/Linux” para referirnos a los sistemas que la mayor
parte de las personas llaman de manera informal “Linux”.
¿Que es servidor Linux?
Es un servidor impulsado por el sistema operativo de código abierto LINUX. Ofrece a las
empresas una opción de bajo costo para entregar contenido, aplicaciones y servicios a
sus clientes. Debido a que Linux es de código abierto, los usuarios también reciben
beneficios de una sólida comunidad de recursos y abogados.
Cada variedad de servidor Linux está diseñada teniendo en cuenta distintos usos:
o Si tiene en ejecución un servidor web, lo más probable es que sea en CentOS.

o Si su aplicación atiende a miles de usuarios, o incluso más, la solución que buscará
será una que esté diseñada para manejar ese tipo de volúmenes, como Red Hat
Enterprise o Ubuntu Server.
Un servidor Linux podría no parecer importante para la integración continua para algunos
y muy importante para otros, en este caso pienso que si seria útil para poder montar un
entorno de integración continua, debido a las siguientes razones.
1) Es un servidor open source.
26
2) Podemos montarlo en maquinas virtuales ya sean en un servidor físico, en caso

de proyectos no muy grandes, debido a la manejabilidad y control del mismo, o en
la nube para proyectos de gran tamaño.
3) Al ser gnu/Linux es muy ligero y no necesita mucho requerimiento de hardware
para funcionar, donde podríamos montar un servidor para cada herramienta que
tengamos, como Jenkins, SonarQube y Nexus repository entre otros.
PUBLISH
• Servidor Jenkins (Ubuntu server 1)

• Servidor SonarQube (Ubuntu server 2)
• Servidor Nexus (Ubuntu server 3).
Figura 17. Jenkins, SonarQube o Nexus en un Servidor Ubuntu.

5.2 SonarQube
El software SonarQube (anteriormente llamado Sonar) es una plataforma de gestión de
calidad de código abierto, dedicada a analizar y medir continuamente la calidad técnica,
desde la cartera de proyectos hasta el método. Si desea ampliar la plataforma SonarQube
con complementos de código abierto [5].
SonarQube es otra de las herramientas que considero importante para el área devOps,
así como para integración continua en proyectos de desarrollo de software, y obviamente
esto ayuda de alguna manera a una buena implementación, en cuanto a código se refiere,
ya que sonar cuenta con más de 20 lenguajes de programación soportados para el
27
análisis, donde los reportes generados por este nos pueden servir para reflexionar y
conocer qué partes o fragmentos de código necesitan ser mejorados.
SonarQube también es flexible en cuanto a integración con otras herramientas, tales
como Jenkins.
¿Qué tipo de problemas podemos resolver?
Algo que debemos tomar muy en cuenta es que un análisis estático del código no es y
no será suficiente para afirmar que nuestro software es de calidad, es por eso que
también necesitamos otro tipo de herramientas de apoyo, como los test unitarios u otros
para verificar el correcto uso y calidad de nuestro software, pero haciendo un análisis del
código sin estar en ejecución podemos detectar elementos como:
o Problemas de Diseño: Podemos detectar problemas en el diseño y arquitectura

del software analizando las dependencias entre las clases del proyecto. Esto nos permite
actuar a tiempo frente a crear un desorden de clases totalmente acopladas y difícilmente
reutilizables.
o Duplicidad de Código: SonarQube nos proporciona métricas de código
duplicado, pudiendo detectar partes de nuestro software se asemejan, pudiendo así
tomar decisiones como desacoplar componentes o aplicar técnicas de refactoring
utilizando el polimorfismo, la herencia y la reutilización de componentes.
o Detección de Vulnerabilidades: SonarQube cuenta con una base de datos de
code smells y errores típicos de programación que detectan, si alguna línea de código
puede estar cometiendo algún problema que pueda vulnerar la seguridad. Por ejemplo,
a la hora de cómo recoger los parámetros o cómo usarlos en nuestras consultas para
evitar SQL Injection.
o Standard de codificación: Avisándonos de partes del código que no cumplan con
el PSR o incluyan malas prácticas a la hora de definir constantes, variables, llamadas a
métodos estáticos.
o Monitorización de Cobertura: En nuestro caso también lo usamos para poder
monitorizar si la cobertura de los test es aceptable y de esta manera tener una visión
global del estado de la cobertura de todos los proyectos e invertir en incrementar el
volumen de test del proyecto.
28
Detectar estos puntos mencionados con sonar son muy importantes para una empresa
de desarrollo de software ya que antes de que el código está ejecutado podemos
detectarlos e ir corrigiendo lo antes posible.
Figura 18. Lenguajes soportados por SonarQube.

Fuente: Pagina SonarQube/Multi-Languaje, recuperado de :
https://www.sonarqube.org/features/multi-languages/
También provee resumen, plasmado en un grafico del resultado de un análisis

programado.
Figura 19. Resumen de resultado después de un análisis.

Fuente: Pagina principal SonarQube/Multi-Languaje, recuperado de https://www.sonarqube.org/
5.3 Nexus repository

29
Nexus es un administrador de repositorios, almacena "artefactos", y se los utilizan para

no tener que depender de algo externo siempre y mantener controladas las librerías
propias de la empresa.
Ya que muchas veces no queremos depender de algo externo a la organización, por
ejemplo, si nuestro proyecto usa maven como servidor web de aplicación, las
dependencias siempre estarán pendientes de maven central (que es externo a la
organización), mientras que si lo descargamos solo al repositorio nexus (una sola vez),
en vez de descargar para cada pc de los desarrolladores, y recién del repositorio
derivamos a los desarrolladores. A continuación, podemos ver un gráfico sobre qué nivel
se encuentra nexus en una organización.
figura 20. dependencias maven sin nexus.
Fuente: javiergarzas.com (01 Agosto 2014), recuperado de:

http://www.javiergarzas.com/2014/08/nexus-artifactory-10-min.html
30
Figura 21. Dependencias maven usando nexus repository.
Fuente: javiergarzas.com (01 Agosto 2014), recuperado de:

http://www.javiergarzas.com/2014/08/nexus-artifactory-10-min.html
5.4 Git
¿Que es git?
Git es un sistema de control de versiones más utilizado actualmente y está llegando a

convertirse (por no decir que ya se lo considera), un estándar para el control de versiones.
Es un control de versiones distribuidas, lo que significa que su copia local de código es

un repositorio completo de control de versiones.
La flexibilidad y popularidad de Git lo convierten en una excelente opción para cualquier

equipo. Muchos desarrolladores, graduados universitarios y desarrolladores amateur ya
saben cómo usar Git. La comunidad de usuarios de Git ha creado muchos recursos para
capacitar a los desarrolladores y la popularidad de Git facilita la obtención de ayuda
cuando la necesita. Casi todos los entornos de desarrollo tienen soporte de Git y las
herramientas de línea de comandos de Git se ejecutan en todos los sistemas operativos
principales lo que lo convierte en multiplataforma en cuanto al uso se refiere [6].
31
Git te permite y te anima a tener múltiples ramas locales que pueden ser totalmente
independientes entre sí. La creación, fusión y eliminación de esas líneas de desarrollo
lleva segundos.
Empresas y proyectos importantes que usan Git como servidor de versiones son:
Google, Facebook, Microsoft, Twitter, Linkedin, Netflix, PostgreSQL, Android, Linux,

Rails, Qt, Gnome y Eclipse.
¿Que es GitHub?
GitHub es una plataforma de desarrollo colaborativo de software para alojar proyectos

utilizando el sistema de control de versiones Git.
GitHub aloja tu repositorio de código y te brinda herramientas muy útiles para el trabajo
en equipo, dentro de un proyecto.
Además de que tu podrías contribuir haciendo alguna mejora en el software de los demás,
para esto github provee una serie de funcionalidades para hacer un fork y solicitar pulls,
Realizar un fork es simplemente clonar un repositorio ajeno (genera una copia en tu
cuenta).
¿Qué es GitLab?
GitLab es la primera aplicación individual construida desde cero para todas las etapas del
ciclo de vida de DevOps para equipos de Producto, Desarrollo, QA, Seguridad y
Operaciones para que trabajen simultáneamente en el mismo proyecto.
GitHub o GitLab son ahora las herramientas mas conocidas a nivel mundial y usadas
para muchos proyectos de diferentes magnitudes, desde proyectos sencillos hasta
proyectos muy complejos.
A continuacion podemos ver un pequeño grafico que nos muestra la capacidad de

compatibiliad de git y github, con varias herramientas de CI.
32
SERVIDOR DE VERSIONES
HERRAMIENTAS DE INTEGRACION CONTINUA
… OTROS
PROCESO FINAL DE INTEGRACION CONTINUA
TESTEO Y GENERACION DEL BUILD
Figura 22. Integracion git con Herramientas de IC.
33
6 Conclusiones
Después de haber revisado las herramientas open source que tenemos disponibles, y en
cómo ellos nos podrían ayudar de gran manera en nuestros proyectos de desarrollo de
software, y que en lo personal más que una opción sería como herramientas importantes
en el área de desarrollo, que en Cochabamba dentro de poco estas herramientas serán
parte del proceso de desarrollo, y que podría ser implantado/aplicado por muchas
empresas de este rubro, debido a que es una forma más de poder decir que la integración
es ágil además de la metodología aplicada, por ejemplo Scrum.
Después de haber revisado las herramientas tales como Jenkins, GoCD y Travis CI,
podemos concluir os siguiente:
 Jenkins:
• Jenkins es una herramienta muy conocida por una gran mayoría de
desarrolladores y personas del rubro del área de sistemas e informática.
• Existe documentación en la web, además de la documentación propia de Jenkins.
• Hay muchas incidencias sobre el manejo de esta herramienta.
• Fácil e intuitivo al momento de aprender a usar esta herramienta.
• Gran cantidad de plugins para configurar Jenkins de acuerdo a nuestras
necesidades y tipos de projectos de software.
• Se integra con muchas otras herramientas alternativas y/o complementarias con
CI.
 GoCD:
• Además de integración continua ofrece herramientas de entrega continua.
• Actualmente es usada por empresas importantes que la recomiendan.
• Configuraciones semejantes a las que ofrece Jenkins (como Jobs, Tasks,
pipelines, etc.).
• No existe muchas incidencias de empresas que lo apliquen en Bolivia u otras, si
bien es usada por empresas importantes en otros países.
 Travis CI:
34
• Travis CI, si bien ofrece herramientas útiles para la integración continua, esta esta
mas pensada para funcionar como microservicio.
• No existe mucha documentación para poder empezar a usar esta herramienta
(primeros pasos).
• Al carecer de otras funcionalidades que ofrecen GoCD y Jenkins esta herramienta
la podríamos calificar con un 3, en un rango de 0-10 tomando en cuenta lo que ofrece y
las incidencias que existen sobre Jenkins y GoCD.
• Una de las razones de no profundizar esta herramienta fue la falta de
documentación y conocimientos que se necesitan para poder empezar a usarla.
35
7 Bibliografía
[1] Fowler Martin. 01 de mayo de (2006). Continous Integration, Continuous Integration.
Recuperado de: https://martinfowler.com/articles/continuousIntegration.html
[2] Paul M.Duvall with Steve M. A. Glover (2007). Continuous integration (Improving
Software Quality and Reducing Risk).Delhi India, India: Pearson Education in South Asia
(p. 29-30).
[3] Jez Humble & David Farley (2010). Continuous Delivery. United States: Addison–
Wesley.
[4] Ferguson S. John (2011). Jenkins: The Definive Guide (Continuous Integration for the
Mases). United States (p. 1).
[5] Ferguson S. John (2011). Jenkins: The Definive Guide (Continuous Integration for the
Mases). United States (p. 3).
[6] Fowler Martin. martinfowler.com, (s.f.). recuperado de:

https://martinfowler.com/delivery.html
[7] Introduction to GoCD, Getting-Started, Concept 2 Pipelines and Materials, (2018).

recuperado de: https://www.gocd.org/getting-started/part-1/
[8] Weyand Christopher, Chronik Jonas, Wolf Lennard, Kötte Steffen, Haase Konstantin,
Felgentreff Tim, Lincke Jens and Hirschfeld Robert (2017). Improving Hosted Continuous
Integration Services. Potsdam-Alemania, (p. 1-3)
36

Herramientas Open Source para La Integración Continua PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Herramientas Open Source para La Integración Continua PDF

Загружено:

Авторское право:

Доступные форматы

Universidad Mayor de “San Simón”

Facultad de Ciencias y Tecnología

Herramientas Open Source para la Integración

Elaborado por: Henry Bustamante Cruz

Esta monografia esta dedicada a toda mi

TABLA DE CUADROS, GRAFICOS Y FIGURAS

Figura 1 – Relación de Integración, Entrega y Despliegue Continua 7

Figura 2 – Característica de Integración Continua 8

Figura 3 – Integracion Continua con Jenkins 13

Figura 4 – Sistema de integración y entrega continua 15

Figura 5 – Servidor y Agentes 16

Figura 6 – Pipelines y Materials 17

Figura 7 – Stages, Jobs and Taks 18

Figura 8 – Representación Pipeline 19

Figura 9 – Nombrar nuevo Pipeline 20

Figura 10 – Seleccionar Material 20

Figura 11 – Definición del Job 21

Figura 13 – Lenguajes soportados por Travis CI 23

Figura 14 – Arquitectura Travis CI 24

Figura 15 – Archivo .travis.yml 25

Figura 17 – Jenkins, SonarQube o Nexus en un Servidor Ubuntu 27

Figura 18 – Lenguajes soportados por SonarQube 29

Figura 19 - Resumen de resultado después de un análisis 29

Figura 20 - dependencias maven sin nexus 30

Figura 21 – Dependencias maven usando nexus repository 31

Figura 22 – Integracion git con Herramientas de IC 33

Actualmente existen varias herramientas para la integración continua en proyectos de

1.1 Antecedentes Generales

¿Qué es integración continua?

Según Martin Fowler la integración continua se define como una:

Figura 1. Relación de Integración, Entrega y Despliegue Continua.

Donde tenemos una pequeña representación de integración continua, y cada

Figura 2. Característica de Integración Continua.

1.2 Antecedentes Específicos

¿Que beneficios tiene la integracion Continua?

• Si no sigue un enfoque continuo, tendrá períodos más largos entre integraciones.

• Construye una base sólida, en el proyecto realizado.

La metodología guía para esta monografía fueron las siguientes:

• Método bibliográfico, por la revisión de documentos, artículos y blogs referentes al

• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

3 Herramientas de código abierto para la integración continua

- Integrity (Construido sobre la base de Ruby).

A continuación, hablaremos de Jenkins y Go CD, para luego hacer una pequeña

4 Herramientas Open Source mas conocidas y usadas de Integracion Continua

o Herramienta de integración continua.

Paso 3: Archivar los

Paso 1: Ejecutar la Paso 5:

Figura 3. Integracion Continua con Jenkins.

Fuente: Elaboracion propia.

Go CD (Continuos Delivery), que en español seria Entrega continua, es otra herramienta

Este grafico representa a grandes rasgos el proceso de integración y despliegue

Figura 4. Sistema de integración y entrega continua.

3.2.1. Conceptos Importantes GoCD

Figura 5. Servidor y Agentes.

Otro concepto igualmente importante es el de un material. Un material es una causa para

Figura 6. Pipelines y Materials.

Fuente: getting-started/Concept 2 Pipelines and Materials, recuperado de:

c) Stages, Jobs y Tasks

Figura 7. Stages, Jobs and Taks.

Go CD hace énfasis en el uso de los pipelines, al igual que otras herramientas de

Figura 8. Representación Pipeline.

Donde para configurarlo se siguen los siguientes 3 pasos según la documentación de Go

Figura 9. Nombrar nuevo Pipeline.