Herramientas Open Source para La Integracion Continua en Proyectos de Desarrollo de Software

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 monografía esta dedicada a toda mi

familia, por todo el apoyo que siempre me
han brindado a mi padre Elio y mama Rosa,
también 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
Introducción 6
1 Generalidades 7
1.1 Antecedentes Generales 7
1.2 Antecedentes Específicos 9
2 Metodología 10
3 Componentes de Integración Continua 10
3.1 Compilador de proyectos y administrador de dependencias 11
3.1.1 Maven 11
3.1.2 Gradle 13
3.2 Controlador de Versiones Git 15
3.3 Repositorio de Artefactos Nexus 17
3.4 Servidores de Integración Continua 19
3.4.1 Jenkins 19
3.4.2 GoCD 21
3.4.2.1 Conceptos Importantes GoCD 23
3.4.3 Travis CI 30
3.4.3.1 Job en Travis CI 32
3.5 Pruebas de calidad del codigo con SonarQube 33
4 Herramienta complementaria al proceso de integración continua 35
4.1 Servidor Linux 35
5 Análisis y evaluación sobre implementar Integración Continua 37
6 Conclusiones 43
7 Bibliografía 45
TABLA DE CUADROS, GRFICOS 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 – Arquitectura Maven 12
Figura 4 – Ejemplo Build de un solo proyecto 14
Figura 5 – Resultado de la ejecución de un proyecto simple 15
Figura 6 – Integración Git con Herramientas de CI 17
Figura 7 – Dependencias Maven sin Nexus 18
Figura 8 – Dependencias Maven usando Nexus Repository 18
Figura 9 – Integración Continua con Jenkins 21
Figura 10 – Sistema de Integración y Entrega Continua 22
Figura 11 – Servidor y Agentes 23
Figura 12 – Pipelines y Materials 24
Figura 13 – Stages, Jobs and Tasks 25
Figura 14 – Representación Pipeline 26
Figura 15 – Nombrar nuevo Pipeline 27
Figura 16 – Seleccionar Material 28
Figura 17 – Definición de Job 29
Figura 18 – Artifact 29
Figura 19 – Lenguajes soportados por Travis CI 30
Figura 20 – Arquitectura Travis CI 31
Figura 21 – Archivo.travis.yml 32
Figura 22 – UI Travis CI 33
Figura 23 – Lenguajes soportados por SonarQube 35
Figura 24 – Resumen de resultado después de un análisis 35
Figura 25 – Jenkins, SonarQube o Nexus en un Servidor Ubuntu 37
Figura 26 – Servidor VPS KAMATERA. 39
Figura 27 – Costo del bug respecto a la Fase del Proyecto Software. 40
Figura 28 – Flujo de Integración Continua 41
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), viene determinada 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].
A continuación, podemos apreciar la relación entre Integración, Entrega y despliegue

continuos (Figura 1).
Figura 1. Relación de Integración, Entrega y Despliegue Continua.
7
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
También podríamos decir que la integración continua es una de las muchas prácticas o
enfoques que existen en proyectos de desarrollo de software ágil en la actualidad, donde
la integración continua a adoptado metodologías ágiles, para poder estar al nivel del
desarrollo ágil hoy en día. 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.
A continuación, lo describiremos en una imagen (Figura 2), lo que acabamos de explicar.
Figura 2. Característica de Integración Continua.
8
Fuente: Paul M.Duvall with Steve M. A. Glover. (2007). Continuous integration (Improving
Software Quality and Reducing Risk) p 15.
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 integración 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 toma mucho tiempo en la
espera de que estos sean testeados por equipos de QA (Quality Assurance).
¿Que beneficios tiene la integración 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 esté 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 que “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].
9
• Reduce el proceso repetitivo manual, lo que significa que libera de alguna manera
al equipo de DevOps de tareas monótonas y permite ser mas productivo al equipo de
desarrollo.
• 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, que es Integración continua.
• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

documentos relacionados al tema de estudio apoyados por la experiencia de las
clases del modulo de Gestión de Entregas y configuración.
3 Componentes de Integración Continua
Hoy en día existen muchos componentes de Integración Continua, pero el propósito de

este documento es de enfocarnos en los que son gratis y algunos open source.
Donde para poder aplicar Integración Continua a un proyecto de software debemos

contar con los siguientes componentes que serian indispensables para poder empezar a
armar nuestro proceso de IC.
10
a) Compilador de proyectos y administrador de dependencias, los mas conocidos y

usados en proyectos Maven o Gradle.
b) Controlador de versiones, tales como Git.
c) Un repositorio de artefactos que sirva para poder identificar las versiones liberadas y
en desarrollo, podrían ser Nexus.
d) Un servidor de Integración Continua, Cuando hablamos de integración continua,

muchas veces lo primero que se nos viene a la mente es Jenkins, pero además
existen otros que serian:
1) Buildbot (Desarrollado en Python, basada en el framework Twisted).
2) Travis CI (es probablemente uno de los servidores CI más sencillos para

empezar según la web).
3) Strider (Está escrito en Node.JS y JavaScript, y utiliza mongoDB como

almacenamiento).
4) Go (fue creado y luego liberado por ThoughtWorks).
5) Integrity (Construido sobre la base de Ruby).
e) Una herramienta para pruebas de calidad de código, podríamos pensar en

SonarQube.
3.1 Compilador de proyectos y administrador de dependencias
Para este caso revisaremos 2 herramientas, que son Maven y Gradle, También podemos
mencionar que el uso de las mismas podría depender en cuestión de preferencias, según
conocimiento, experiencias o tipos de proyectos a los cuales aplicaremos estas
herramientas, para la gestión y construcción de proyectos Java (generación del build).
3.1.1 Maven
Maven es una herramienta open source, para la gestión y construcción de proyectos

Java, en la documentación lo describen como “acumulador de conocimiento”, esto debido
a que Maven nos ayuda en la administración de dependencias para nuestro proyecto, de
tal forma que quede organizado nuestro código.
11
Maven esta definido por un archivo POM (Project Object Model), en el cual definimos las
librerías, dependencias y configuraciones que necesitemos para nuestro proyecto, de tal
forma que todo quede centralizado en ese archivo y mantengamos un orden en el código
(estructurado).
Podriamos decir que Maven simplifica el proceso de build del código, lo que nos permite
compilar cualquier tipo de proyecto Java, de la misma manera, librándonos de lo que
sucede por detrás.
La arquitectura de Maven se describe en la siguiente Figura 3.
Figura 3. Arquitectura Maven.

Fuente: Maven cheat sheet recuperado de: https://zeroturnaround.com/rebellabs/maven-cheat-
sheet/
¿Cómo nos ayuda en la gestión de nuestro proyecto?
Maven es capaz de gestionar nuestro proyecto desde la etapa de comprobación del

código, hasta el despliegue de la aplicación, luego pasando por la ejecución de pruebas
y generación de informes.
Para llevar a cabo lo que mencionamos Maven cuenta con un ciclo del build que es el
siguiente:
a) validate: Validar que el proyecto es correcto.
b) compile: Compilación del código
c) test: Probar el código fuente usando una herramienta o framework de pruebas

unitarias.
12
d) package: Empaquetar el código compilado y transformarlo en algún tipo .jar o

.war.
e) integration-test: Procesar y desplegar el código en algún entorno donde puedan

llevarse a cabo la ejecución de las pruebas de integración.
f) verify: Verificar que el código empaquetado el valido y cumple los criterios de

calidad.
g) install: instalar el condigo empaquetado en el repositorio local de Maven, para

usarlos como dependencias de otros proyectos.
h) deploy: desplegar el proyecto a un entorno.
3.1.2 Gradle
Gradle es una herramienta de automatización de construcción de nuestro código, que se

consume de las aportaciones que han realizado herramientas como Ant y Maven, y que
intenta llevarlo un paso mas adelante. Gradle se apoya en Groovy y en un DSL (Domain
Specific Language) para poder trabajar con un lenguaje sencillo y claro a la hora de
construir el build, en comparación con Maven.
Al igual que Maven, Gradle cuenta también con un ciclo de vida del build, los cuales están
compuestos por tres fases, inicialización, configuración y ejecución, a continuación,
veremos que hace cada una de estas fases.
a) Inicialización, Durante la fase de inicialización, Gradle determina qué proyectos

participarán en la compilación y crea una instancia de proyecto para cada uno de
estos proyectos.
b) Configuración, Durante esta fase se configuran los objetos del proyecto. Se

ejecutan los scripts de compilación de todos los proyectos que forman parte de la
compilación.
c) Ejecución, Gradle determina el subconjunto de las tareas, creadas y configuradas

durante la fase de configuración, para ser ejecutadas. El subconjunto está
determinado por los argumentos de nombre de tarea pasados al comando Gradle
13
y al directorio actual. A continuación, Gradle ejecuta cada una de las tareas

seleccionadas.
Un pequeño ejemplo sobre las fases del ciclo del build de Gradle lo vemos en el siguiente
ejemplo obtenido de la documentación de Gradle, descrita en la Figura 4.
Figura 4. Ejemplo Build de un solo proyecto.

Fuente: Build Lifecycle recuperado de:
https://docs.gradle.org/current/userguide/build_lifecycle.html
El resultado de el ejemplo en la Figura 4, esta descrito en la Figura 5.
14
Figura 5. Resultado de la ejecución de un proyecto simple.

Fuente: Build Lifecycle recuperado de:
https://docs.gradle.org/current/userguide/build_lifecycle.html
3.2 Controlador de Versiones 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].
15
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 continuación, podemos ver un pequeño gráfico (Figura 6) que nos muestra la capacidad
de compatibilidad de git y github, con varias herramientas de CI.
16
SERVIDOR DE VERSIONES
HERRAMIENTAS DE INTEGRACION CONTINUA
… OTROS
PROCESO FINAL DE INTEGRACION CONTINUA
TESTEO Y GENERACION DEL BUILD
Figura 6. Integración Git con Herramientas de CI.

Fuente: Elaboración propia.
3.3 Repositorio de Artefactos Nexus
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 (revisar Figura 7 y Figura 8), 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.
17
Figura 7. Dependencias Maven sin Nexus.

Fuente: javiergarzas.com (01 agosto 2014) recuperado de:
http://www.javiergarzas.com/2014/08/nexus-artifactory-10-min.html
Figura 8. Dependencias Maven usando Nexus repository.

Fuente: javiergarzas.com (01 agosto 2014) recuperado de:
http://www.javiergarzas.com/2014/08/nexus-artifactory-10-min.html
18
3.4 Servidores de Integración Continua
3.4.1 Jenkins
Jenkins hace énfasis en la integración continua, John Ferguson Smart (2011) sostiene
que “una buena infraestructura de Integración Continua puede agilizar el proceso de
desarrollo de tal forma que 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 Integración Continua”. [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 más sobresalientes de Jenkins se describen a continuación:
o Herramienta de integración continua.
o Identifica las distintas tareas en (Jobs).
19
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.
A continuación, un pequeño esquema (Figura 9), de cómo la integración continua se

refleja en Jenkins.
20
Figura 9. Integración Continua con Jenkins.

por ejemplo:
Para generar un build de un proyecto “X” se siguen algunos pasos previos, que sería
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 además que pueda generar el build del proyecto.
3.4.2 GoCD
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
21
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. Hoy en día Thougtworks aún sigue colaborando dando
soporte a GoCD y esto se refleja en algunos servicios plus que ofrece bajo un coste, el
servicio plus es de (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 gráfico sacado de la documentación de la
página oficial de GoCD.
La siguiente imagen (Figura 10), 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.
Figura 10. Sistema de integración y entrega continua.
22
Fuente: Documentación GoCD recuperado de: https://docs.gocd.org/current/
3.4.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,
como podemos ver en la Figura 11.
Figura 11. 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
23
como una canalización. GoCD proporciona diferentes construcciones de modelado

dentro de un pipeline, como etapas, trabajos y tareas. Los veremos en más detalle mas
adelante. 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. Una
representación gráfica de pipeline y materials está ilustrado en la Figura 12.
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]
Figura 12. 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 Job 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 Job se ejecuta una después
de la otra, y en su configuración predeterminada, si una tarea falla, ninguna de las tareas
24
siguientes a esa se ejecuta. Entonces se considera que el Job ha "fallado". El aspecto

más importante de un Job es que un solo agente tiene que recoger y terminar un Job.
Por lo tanto, puede tener la garantía de que todas las tareas de un Job 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.
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.
Todo lo que acabamos de explicar sobre Stages, Job y Taks se resumen en la Figura 13.
Figura 13. Stages, Jobs and Taks.

Fuente: getting-started/Concept 4: Stages, jobs and tasks
25
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 también y no se iniciarán,
a esto lo denomina un pipeline fallido.
En el siguiente gráfico (Figura 14), 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 14. 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.
26
Paso 1: hacemos click en botón Add new Pipeline, luego nos mostrará los tabs
necesarios para configurar nuestro pipeline, don de ponemos el nombre de nuestro
pipeline y el grupo al que pertenecerá este (Figura 15).
Figura 15. 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 sería 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) véase la Figura 16.
27
Figura 16. Seleccionar Material.

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,
ver Figura 17.
28
Figura 17. Definición de Job.

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 18).
Figura 18. Artifact.

Fuente: GoCD Documentation/Concepts in GoCD:
Artifacts recuperado de: https://docs.gocd.org/current/introduction/concepts_in_go.html
29
3.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.
Travis también provee un considerable numero de lenguajes soportados para poder

trabajar en un entorno de integración continua revisar (Figura 19).
Figura 19. Lenguajes soportados por Travis CI.

Fuente: Travis CI – Getting Started recuperado de: https://docs.travis-ci.com/.
30
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
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]
A continuación, podemos apreciar un vistazo de la arquitectura de Travis CI (Figura 20).
Figura 20. Arquitectura Travis CI.
31
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).
3.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 CI podremos ver que
nada pasa mientras hagamos varios commits.
Un pequeño ejemplo del archivo sería el siguiente (Figura 21).
Figura 21. Archivo.travis.yml.

Revisando un poco la herramienta UI, esta no presenta una variedad de opciones a nivel
de UI (Figura 22), en comparación con GoCD o Jenkins los cuales te facilitan con una
gran variedad de opciones y fácil uso bajo un seguimiento de la documentación, Pero con
Travis CI no es el caso, en la versión gratuita.
32
Figura 22. UI Travis CI.

3.5 Pruebas de calidad del código con 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
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.
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
33
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.
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.
Los lenguajes soportados por SonarQube son bastantes como se muestran en la
siguiente imagen (Figura 23).
34
Figura 23. Lenguajes soportados por SonarQube.

Fuente: Página SonarQube/Multi-Languaje recuperado de:
https://www.sonarqube.org/features/multi-languages/
También provee un resumen, plasmado en un gráfico (Figura 24) del resultado de un
análisis programado.
Figura 24. Resumen de resultado después de un análisis.

Fuente: Página principal SonarQube/Multi-Languaje recuperado de https://www.sonarqube.org/
4 Herramienta complementaria 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 anteriormente, y entre
las mas destacadas se eligieron las siguientes.
4.1 Servidor Linux
35
¿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.
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.
36
En resumen lo podemos mostrar plasmado en una imagen descrita en la Figura 25.
Figura 25. Jenkins, SonarQube o Nexus en un Servidor Ubuntu.

5 Análisis y evaluación sobre implementar Integración Continua
Hasta este punto ya hemos visto de cómo se compone el proceso de integración continua,
además de las herramientas que se han revisado en este documento se necesitan a las
personas (encargados) de llevar a cabo la implementación de Integración Continua. Las
herramientas revisadas corresponden un 50 % de Integración continua en el sentido de
que están ahí, pero necesitamos actores que serían los que llevarían a cabo la
implementación y el uso de la misma, en si estos actores serian: developers, Devops,
QA, proyecto X, IT y factor económico e infraestructura.
Para llevar a cabo esta implementación (Integración Continua) podría variar, de acuerdo
a la magnitud del proyecto, por ejemplo, para una Startup o una empresa grande.
Para empezar a desarrollar el análisis primero describiremos que es una Startup, Blank,
Steven && Dorf Bob (2012) afirman que “es una organización temporal en busca de un
modelo de negocio escalable, repetitivo y rentable” [9]. Para una Startup se podría aplicar
Integración continua, es decir que implementar CI en una Startup marcaria diferencia con
respecto a otras Startups, y el costo a lo mucho talvez seria en el sentido del esfuerzo
que se aplicaría en la implementación de CI, ya que en el sentido económico seria barato
37
ya que podríamos empezar a usar herramientas open source o que en su defecto son
gratis, lo que escatimaría gastos, estas herramientas serian algunas que hemos
mencionado como Jenkins, Git, Maven, etc. Donde luego el proyecto lo podríamos alojar
en un servidor local, Linux por ejemplo o un servidor de características considerables en
la web para empezar y luego ir escalando incrementando las características del servidor
de acuerdo a lo que se vaya requiriendo como memoria RAM, procesadores, etc. Claro
que también dependería del factor económico disponible para invertir (ya que los
servidores en la nube tienen costo, si bien en un inicio muchos son free por un periodo
corto).
A continuación, una lista top 14 de servidores aceptables a precios accesibles:
Kamatera, A2Hosting, Hostwinds, Contabo, Weblink, MochaHost, Hostinger, 1&1,

DreamHost, InterServer, Host1Plus, MilesWeb, LiquidWeb y GreenGeeks.
Por ejemplo, Kamatera ofrece las siguientes características, ver Figura 26.
38
Figura 26. Servidor VPS KAMATERA.

Fuente: 14 Mejores Proveedores de Alojamiento VPS Baratos en 2018(Comparación)
recuperado de: https://www.wponeapp.com/es/mejor-barato-proveedor-alojamiento-vps/
En cambio para una Empresa Establecida (que tiene millones de clientes), podríamos
aplicar Integración Continua, pero los cuales si tendrían costes (que viendo el lado
positivo de esto, serian como una inversión), debido a que el resultado de esta
implementación seria a favor de la empresa y también para los clientes (indirectamente),
además de la mejora en el desarrollo y control de calidad, pero antes de llevar a cabo
esta implementación se debería realizar una evaluación y análisis del estado del producto
(proyecto) en cuestión que se esta desarrollando (o que ya estaría en producción), y la
viabilidad de poder aplicarlo. En resumen, se verían cuestiones de adaptación y por otro
lado el tema cultural, donde pueda que por esos dos factores la empresa evitaría aplicar
Integración Continua aun sabiendo las ventajas que esta brinda.
39
El lado positivo de la incorporación de las pruebas y la inspección continua en el proceso

de CI es valioso para los desarrolladores y administradores por igual. Es útil disponer de
una línea de tiempo histórica de métricas para aprovechar y buscar a las tendencias, los
puntos débiles del código, etc.
Los indicadores de mayor interés dependerán de los requisitos clave del proyecto.
Algunas métricas de código típicos incluyen:
• Pruebas Unitarias
• Complejidad
• Dependencia
• Longitud
CI reduce los gastos generales, ya que la sobrecarga inicial de la creación/adopción de

un sistema de CI se ve compensado por las horas-hombre que se ahorran después.
Encontrar un error mientras estamos desarrollando es la forma más barata posible para
encontrarlo. Si el fallo se encuentra en fases más avanzada el coste es más alto. Todos
hemos visto alguna vez un diagrama como la Figura 27.
Figura 27. Costo del bug respecto a la Fase del Proyecto Software.
Fuente: The cost to fix bugs can increase dramatically over time. Patton, R. (2005). Software
Testing (2nd ed.) (p-18).
40
Patton, R. (2005). Software Testing (2nd ed.) (p-18) afirman que “Un error encontrado y
corregido durante las primeras etapas cuando se escribe la especificación podría costar
casi nada, o $ 1 en nuestro ejemplo (Figura 27). El mismo error, si no se encuentra hasta
que el software esté codificado y probado, puede costar entre $ 10 y $ 100. Si un cliente
lo encuentra, el costo podría ser fácilmente de miles o incluso millones de dólares.” [10]
En el caso de aplicarlo el flujo de Integración continua que se aplicaría en este tipo de

empresas (empresas establecidas) seria el que se muestra en la Figura 28. Donde la
aplicación de Integración Continua debería hacerse de manera progresiva debido a que
el equipo de desarrollo, Devops y demás involucrados deben adaptarse, ya que esto
podría afectar en un principio el avance que el equipo y no parecería buena idea si el
producto (software) en cuestión ya este en ultimas etapas de poder concretarse, ya que
podría verse afectado las entregas programadas que puedan haber ya establecidas con
los clientes.
Figura 28. Flujo de Integración Continua.

Fuente: Continuous Delivery en GeneXus recuperado de: https://www.federico-
toledo.com/continuous-delivery-en-genexus/
Está claro que las herramientas dependerán si la empresa actualmente ya está usando,
parte de los componentes de Integración Continua que mencionamos en el documento,
41
y podríamos ir adecuando según lo requiera, por ejemplo, si está usando Jenkins,

SonarQube y Maven, podríamos complementarlo con lo que aun no este en el flujo de
Integración que la empresa tiene.
42
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 proyectos 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:
43
• 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.
44
7 Bibliografía
[1] Fowler Martin. 01 de mayo de (2006). Continous Integration, Continuous Integration,
(consultado 28 de octubre de 2018). 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 (p. 14 - 20)
[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, (consultado 28 de octubre de 2018). recuperado de:

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

28 de octubre de 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)
[9] Blank, Steven && Dorf Bob (2012), The Step-by-Step Guide for Building a Great
Company (Preface).
[10] Patton, R. (2005). Software Testing (2nd ed.) (p-18).
45

Herramientas Open Source para La Integracion Continua en Proyectos de Desarrollo de Software

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Herramientas Open Source para La Integracion Continua en Proyectos de Desarrollo de Software

Caricato da

Copyright:

Formati disponibili

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 monografía esta dedicada a toda mi

TABLA DE CUADROS, GRFICOS Y FIGURAS

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

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:

A continuación, podemos apreciar la relación entre Integración, Entrega y despliegue

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

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

A continuación, lo describiremos en una imagen (Figura 2), lo que acabamos de explicar.

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

1.2 Antecedentes Específicos

¿Que beneficios tiene la integración Continua?

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

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 Componentes de Integración Continua

Hoy en día existen muchos componentes de Integración Continua, pero el propósito de

Donde para poder aplicar Integración Continua a un proyecto de software debemos

a) Compilador de proyectos y administrador de dependencias, los mas conocidos y

b) Controlador de versiones, tales como Git.

d) Un servidor de Integración Continua, Cuando hablamos de integración continua,

1) Buildbot (Desarrollado en Python, basada en el framework Twisted).

2) Travis CI (es probablemente uno de los servidores CI más sencillos para

3) Strider (Está escrito en Node.JS y JavaScript, y utiliza mongoDB como

4) Go (fue creado y luego liberado por ThoughtWorks).

5) Integrity (Construido sobre la base de Ruby).

e) Una herramienta para pruebas de calidad de código, podríamos pensar en

3.1 Compilador de proyectos y administrador de dependencias

Maven es una herramienta open source, para la gestión y construcción de proyectos

La arquitectura de Maven se describe en la siguiente Figura 3.

Figura 3. Arquitectura Maven.

¿Cómo nos ayuda en la gestión de nuestro proyecto?

Maven es capaz de gestionar nuestro proyecto desde la etapa de comprobación del

a) validate: Validar que el proyecto es correcto.

b) compile: Compilación del código

c) test: Probar el código fuente usando una herramienta o framework de pruebas

d) package: Empaquetar el código compilado y transformarlo en algún tipo .jar o

e) integration-test: Procesar y desplegar el código en algún entorno donde puedan

f) verify: Verificar que el código empaquetado el valido y cumple los criterios de

g) install: instalar el condigo empaquetado en el repositorio local de Maven, para

h) deploy: desplegar el proyecto a un entorno.

Gradle es una herramienta de automatización de construcción de nuestro código, que se

a) Inicialización, Durante la fase de inicialización, Gradle determina qué proyectos

b) Configuración, Durante esta fase se configuran los objetos del proyecto. Se

c) Ejecución, Gradle determina el subconjunto de las tareas, creadas y configuradas

y al directorio actual. A continuación, Gradle ejecuta cada una de las tareas

Figura 4. Ejemplo Build de un solo proyecto.

El resultado de el ejemplo en la Figura 4, esta descrito en la Figura 5.

Figura 5. Resultado de la ejecución de un proyecto simple.

3.2 Controlador de Versiones Git

Git es un sistema de control de versiones más utilizado actualmente y está llegando a

Es un control de versiones distribuidas, lo que significa que su copia local de código es

La flexibilidad y popularidad de Git lo convierten en una excelente opción para cualquier

Google, Facebook, Microsoft, Twitter, Linkedin, Netflix, PostgreSQL, Android, Linux,

GitHub es una plataforma de desarrollo colaborativo de software para alojar proyectos