UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCION DE POSGRADO

“INTEGRACION CONTINUA”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSION II

POSTULANTE : ELVIS ROGELIO RAMIREZ IRIARTE

TUTOR : Ing. ABEL DIAZ CASTILLO

Cochabamba - Bolivia

2019
 Dedicatoria

Dedicado a mis padres Rogelio Ramirez y Juanita Iriarte,

a los padres de mi madre, Hilarion Iriarte y Juana Jarajuri.

i
 Agradecimientos
Durante la etapa de mi estudio, hasta finalizar mis estudios, existen un grupo de
personas a las que no puedo dejar de reconocer y hacer mension debido a que
durante todo este tiempo estuvieron presentes de una u otra forma evitando que me
perdiera en el proceso.
A Dios….por brindarme la vida y darme las bendiciones de mi vida.
A mí familia… sin duda uno de los principales precursores de este logro, hicieron todo
lo posible por ayudarme siempre, nunca se rindieron con mi aprendizaje y me
impulsaban para que yo pudiera seguir con mis estudios.
A mi hijo y mi señora que por brindarme la motivación de continuar y impulsarme a
seguir, por ser el motor que sin saberlo mi hijo ayudo a culminar este logro.
A Jose Maria Zambrana y Diego A. Zambrana por apoyarme y alentarme a seguir,
porque nunca dudaron de mí capacidad y siempre me incentivaron a seguir adelante.

ii
 RESUMEN

Este trabajo muestra una visión general de la importancia de la INTEGRACIÓN CON-

TINUA en el proceso de desarrollo de software.
En diversas ocasiones los desarrolladores hacen un deploy (despliegue)de las aplica-
ciones de forma manual; es decir, si se habla de un sitio web, el primer paso a realizar
es subir todos los cambios en la rama principal, posteriormente se ejecuta todas las
pruebas unitarias, si las pruebas son exitosas se procede a compilar el proyecto y subir
todos los cambios a producción.

El cliente ya podrá hacer uso de los nuevos características de la aplicación, siempre

y cuando ninguno de los pasos anteriores haya fallado.

Esta secuencia de pasos a menudo son tediosos e involucran una cierta cantidad
de tiempo, tiempo en el que regularmente como desarrollador se demora demaciado.
Por lo tanto para evitar esto problemas es que surge la integración continua, ya que
esta es una serie de buenas prácticas con la finalidad principal de realizar comproba-
ciones automáticas y periódicas de la evolución de un proyecto de manera que sirva
para agilizar la producción de las aplicaciones.

En la actualidad los procesos de integración continua está ayudando a la persona

inmersa en desarrollo de software a ser más ágil y competitivo en su transformación di-
gital de cirta manera y existe encargado solo de dedicarse a solo brindar todos procesos
al desarrollador.

iii
ÍNDICE GENERAL

DEDICATORIA I

AGRADECIMIENTOS II

RESUMEN III

1. Introducción 1

2. Antecedentes 4
2.1. Antecedentes generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Antecedentes específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. Metodología 8

4. Integración continua 9
4.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Importancia de la integración continua . . . . . . . . . . . . . . . . . . . . 11
4.4. Sistema de integración continua . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. ¿Qué es la entrega continua? . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Control de versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. GitFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7.1. Ramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7.2. Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.8. Ventajas de la integración continua . . . . . . . . . . . . . . . . . . . . . . 17
4.9. Desventajas de la integración continua . . . . . . . . . . . . . . . . . . . . 18

5. Pasos a realizar para integración continua 19

5.1. Un único código fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Automatizar la compilación del proyecto . . . . . . . . . . . . . . . . . . . 19
5.3. Sistemas que realizan sus propias pruebas . . . . . . . . . . . . . . . . . 20
5.4. Integración diaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Linea principal operativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Reparación inmediata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.7. Integración rápida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. Pruebas en una replica del entorno de producción . . . . . . . . . . . . . 21

iv
 5.9. Accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.10.Buena comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.11. Despliegue automatizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6. Herramientas para crear un entorno de Integración continua 23

6.1. Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. Integración continua con jenkins . . . . . . . . . . . . . . . . . . . 24
6.2. GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4. Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5. Apache Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.6. Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.6.1. Comandos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7. Conclución 36

8. Anexo I: Dockerfile JENKINS 39

8.1. Ejemplo Dockerfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Micro servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

v
ÍNDICE DE FIGURAS

1.1. Procesos de la integración continua . . . . . . . . . . . . . . . . . . . . . 1

1.2. Procesos de Desarrollo de software . . . . . . . . . . . . . . . . . . . . . 2
1.3. Flujo automatización de herramientas . . . . . . . . . . . . . . . . . . . . 3

2.1. Flujo del trabajo de integración continua . . . . . . . . . . . . . . . . . . . 5

2.2. Interacción de las herramientas . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Construyendo una tubería de entrega continua . . . . . . . . . . . . . . . 7

4.1. Integración continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2. Ciclo de vida de devOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. CICD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Proceso de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. git workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Rama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7. Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1. Herramientas más utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2. Ventana de Inicio jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Pagina principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Ventana de dashboard de jenkins . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. Paso general de la creación de la tarea . . . . . . . . . . . . . . . . . . . 26
6.6. Paso Source Code Management de la tarea . . . . . . . . . . . . . . . . . 27
6.7. Paso Build Triggers de la tarea . . . . . . . . . . . . . . . . . . . . . . . . 27
6.8. Paso Build Environment de la tarea . . . . . . . . . . . . . . . . . . . . . 28
6.9. Paso Build de la tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.10.Paso Build Triggers de la tarea . . . . . . . . . . . . . . . . . . . . . . . . 29
6.11. Paso Logs de la tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.12.Herramienta GitLab y jenkins . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.13.SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.14.Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8.1. Implementación con jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.2. Arquitectura implementada . . . . . . . . . . . . . . . . . . . . . . . . . . 42

vi
 1 INTRODUCCIÓN

En el área de informática según, Martin Fowler (2019) Continuous Integration 1 Re-

marca que la Integración Continua es una práctica de desarrollo de software mediante
la cual el desarrollador combina sus cambios del código en un repositorio central de
forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas.
La integración continua se refiere en su mayoría a la fase de creación o integración
del proceso de publicación de software y conlleva un componente de automatización.
Uno de los objetivos clave de la integración continua consiste en encontrar y arreglar
errores con mayor rapidez, mejorar la calidad del software y reducir el tiempo que se
tarda en validar y publicar nuevas actualizaciones de software.

Figura 1.1: Procesos de la integración continua

Fuente: https://integraconsultores.es/servicios/desarrollo-ad-
hod/saber-mas/attachment/integracion_continua

Es un tema el cual se ha vuelto bastante popular y eficiente en los últimos años

principalmente por el impulso que ha tenido por aporte de grandes empresas las cua-
les basan su desarrollo en un enfoque ágile, hablar de integración continua, también
1
Integración Continua

1
esta inmerso: entrega continua y despliegue continuo. La integración continua se re-
fiere en su mayoría a la fase de creación o integración del proceso de publicación de
software y conlleva un componente de automatización por ejemplo un servicio de ver-
siones y un componente cultural aprender a integrar con frecuencia.

Los objetivos clave de la integración continua consisten en encontrar y arreglar erro-

res con mayor rapidez, mejorar la calidad del software y reducir el tiempo que se tarda
en validar y publicar nuevas actualizaciones de software.

Figura 1.2: Procesos de desarrollo de software

Elaboración propia. Fuente Adanza, F.(2016)

Prácticamente la integración continua es una práctica de desarrollo en la cual los

desarrolladores integran su código a un repositorio central, esto de forma periódica y
variable, varias veces por día.Cada vez que un miembro del equipo realiza un commit
sobre el control de versiones (git por ejemplo), el proyecto se compila y se ejecutan to-
das sus pruebas unitarias, todo esto de forma automática. La integración continua hace
énfasis en la ejecución automática de las pruebas unitarias. De esta forma se garantiza
que los errores se detecten en una etapa temprana en el desarrollo de software, con lo
cual facilita la corrección de los mismos.

2
 Figura 1.3: Flujo automatización de herramientas recuperado de
https://blog.callr.tech/gitlab-ansible-docker-ci-cd/

Con integración continua se alienta al desarrollador a realizar “commit”2 de su có-

digo de forma constante, después de completar tareas pequeñas. Esto tiene muchas
ventajas, por ejemplo, el equipo de desarrollo estará siempre trabajando con una ver-
sión actualizada del proyecto, cada commit será una posible versión y por supuesto,
al estar actualizando el repositorio en una forma constante evitaremos que en algún
momentos salgan a relucir cientos de conflictos al realizar el merge.3
Finalmente al compilar y testear el proyecto por cada uno de los “commitrealizado a
una rama en concreto (por defecto master), se garantiza que la rama se encuentre libre
de bugs (por lo menos los que contentas test) y que se mantenga una calidad constante.

2
Confirmar un conjunto de cambios provisionales de forma permanente
3
fusionar código

3
 2 ANTECEDENTES

Martin Fowler “La integración continua es una práctica de desarrollo de software

en la cuál los miembros del equipo integran su trabajo de forma frecuente. Cada inte-
gración desencadena una ejecución de pruebas que permiten detectar errores lo mas
rápido posible.”

Por tanto con el concepto anterior la integración continua es una serie de pasos de
buenas prácticas con el fin de realizar comprobaciones automáticas y periódicas de
código con el objetivo de detectar errores lo mas antes posible y analizar la calidad de
software es decir el control constante del desarrollo de software.

Implementar esta práctica exitosamente involucra ciertos requisitos según Abbott,

M.L. and Fisher, M.T. (2015):

Tener un repositorio maestro donde esté disponible todo el código fuente y del
que cualquier integrante del equipo pueda obtenerlo.

Automatizar el proceso de integración para que cualquier persona pueda generar

una versión ejecutable del sistema a partir del código fuente.

Automatizar las pruebas para que sea posible ejecutar la matriz (suite) de pruebas
en cualquier momento con un solo comando.

Asegurar que cualquiera puede obtener el ejecutable más reciente y tener la con-
fianza de que es la mejor versión hasta el momento.

Todo esto requiere bastante disciplina y requiere un esfuerzo significativo para intro-
ducirlo a un proyecto, pero una vez habilitado es sencillo mantenerlo y brinda grandes

4
beneficios.

Para alcanzar el objetivo principal existen herramientas muy potentes que facilitan
la realización de cada una de estas tareas.

Figura 2.1: Flujo del trabajo de integración continua

Fuente: https://www.uxland.es/devops-integracion-continua

2.1. Antecedentes generales

En la actualidad una de las principales características de las aplicaciones es la ca-

pacidad de poder integrarse e interactuar con distintas aplicaciones o/u herramientas
(Stafford, n.d.) se puede interactuar e integrar unas con otras pero es necesario veri-
ficar la interacción entre ellas, entre los componentes la eficiencia del mismo, con ello
construir y obtener un software eficiente.

2.2. Antecedentes específicos

El problema de investigación busca guiar el proceso de la implementación y mostrar

el cambio de proceso de desarrollo de software con el uso integración continua. en la
solución de conflictos de integración de código, pruebas, despliegue, donde se apro-
vechar aprovechar las características principales de “integración continua” para poder
ejecutar e interactuar con los constantes cambios en el proceso de desarrollo de soft-
ware. El documento trata de hacer conocer las ventajas y el proceso de implementación
de la integración continua.

5
 Figura 2.2: Interacción de las herramientas
Fuente: https://www.autentia.com/2018/08/17/entendiendo-devops-en-
5-minutos/

6
 Figura 2.3: Construyendo una tubería de entrega continua
Fuente: https://dzone.com/articles/building-a-continuous-delivery-
pipeline-using-jenk

7
 3 METODOLOGÍA

La metodología propuesta revisado en Gómez-Luna & Betancourt-Buitrago, L. (2014).

para este trabajo es la de “Revision bibliográfica”la que puede ser aplicada a cualquier
tema de investigación para determinar la relevancia e importancia del mismo y asegu-
rar la originalidad de una investigación e indagación del mismo.
Esto permite que otras personas consulten las fuentes bibliográficas citadas, esto con
el objetivo de entender y quizá continuar con la investigación de el trabajo realizado.
Mediante una macro búsqueda que permite la identificación de los documentos refe-
rentes al tema de investigación.

A continuación, se mencionan los métodos de investigación que serán utilizados en

el presente trabajo:

Método bibliográfico Debido a que se realizará la lectura, compilación de libros

relacionados, foros páginas relacionadas u oficiales en la web de este tipo de
buena práctica al tema de estudio.
El trabajo de revisión bibliográfica constituye una etapa fundamental de todo pro-
yecto de investigación y debe garantizar la veracidad del trabajo.

Método analítico Debido a que se procederá a revisar y analizar ordenadamente

documentos enlaces relacionados al tema de estudio.

8
 4 INTEGRACIÓN CONTINUA

¿Qué es la integración continua?

Como muchos otros procedimientos de la metodología ágil una de las funciones

principales de la CI1 o Integración Continua, es facilitar el trabajo al desarrollador.
Cuando hablamos de integración contínua, nos referimos a la creación de código entre
diferentes desarrolladores y bajo una minuciosa comprobación del mismo. Para hacer
que esto sea posible y fácil, no se espera a que el código esté finalizado, como se hacía
en los métodos convencionales o de cascada, sino que se llega a dividir el trabajo en
pequeñas tareas,también denominadas sprints, que no suponen un gran esfuerzo ni se
necesita una gran inversión de tiempo, de forma que se puedan ir comprobando dichas
tareas frecuentemente.
Estas comprobaciones se deben llevar a cabo por lo menos una vez al día y suelen ser
realizadas al finalizar cada jornada laboral. En base a los resultados, se puede seguir
creando o entrando en la fase de modificación, donde una vez detectado el error, el
grupo decidirá cómo se puede superar y para ello, que deben modificar.

4.1. Definición

Es el proceso automatizado para ensamblar y probar versiones ejecutables del soft-

ware, de manera que el equipo de desarrollo pueda construir y probar varias veces al
día el software en la que se esta trabajando.
Este concepto es conocido como “integración continua” y es una de las prácticas de Ex-
treme Programming, sin embargo no es necesario estar siguiendo Extreme Program-
ming para aplicarla.
1
Integración Continua

9
 La integración continua es una práctica de desarrollo que requiere que los desa-
rrolladores integren el código en un repositorio compartido varias veces al día. Cada
registro se verifica luego mediante una compilación automatizada, lo que permite a los
equipos detectar problemas en una etapa temprana. Al integrarse regularmente, puede
detectar errores rápidamente y localizarlos más fácilmente.
debe tomar Nota: a lo largo de este artículo se menciona frecuentemente el con-
cepto de “integrar”software. Esto se refiere al proceso específico de generar una versión
ejecutable de un software, que puede involucrar compilar el código fuente, empaquetar,
incluir archivos de configuración, etc.

Figura 4.1: Integración continua

Fuente: http://danielcoding.net/tag/continuous-integration

4.2. Características

Como muchos otros procedimientos de la metodología ágil una de las funciones

principales de la Integración Continua, Según el libro de Duvall (2007, P. M. Duvall,
S. Matyas, and A. Glover) Cuando se habla de integración contínua, se referiré a la
creación de código entre diferentes desarrolladores y bajo una minuciosa comprobación
del mismo. Para hacer que esto sea posible y fácil, no se espera a que el código esté
finalizado, como se hacía en los métodos convencionales o de cascada, sino que se

10
llega a dividir el trabajo en pequeñas tareas,también denominadas sprints 2 , que no
suponen un gran esfuerzo ni se necesita una gran inversión de tiempo, de forma que
se puedan ir comprobando dichas tareas frecuentemente. Estas comprobaciones se
deben llevar a cabo por lo menos una vez al día y suelen ser realizadas al finalizar
cada jornada laboral. En base a los resultados, se puede seguir creando o entrando en
la fase de modificación, donde una vez detectado el error, el grupo decidirá cómo se
puede superar y para ello, que deben modificar.
Ágil 3 implica trabajar de forma rápida e intentar reducir el rango de errores al mínimo
posible. Una forma de poder conseguirlo es fomentando el trabajo en equipo, de forma
que se ayuden para superar las trabas y aprendan los unos de los otros.
Otra característica es desglosar los grandes proyectos en pequeñas tareas, de forma
que el trabajo se mucho más llevadero, la presión menor y los tiempos de entrega /
validación, más frecuentes.
Por lo tanto, un flujo contínuo de revisiones, opiniones, pruebas, retro alimentación
entre el cliente y entre los miembros del equipo, superación de errores, cuidar el código
y trabajar cómodo hace que este tipo de prácticas sean tan frecuente hoy en día. Ahora
es posible que un trabajo sea más eficiente y rentable.

4.3. Importancia de la integración continua

Beck realizó una publicación donde puso énfasis en la importancia que implica bá-
sicamente con el cumplimiento del objetivo del desarrollo de las aplicaciones modernas
que es contar con múltiples desarrolladores que trabajen de forma simultánea en dis-
tintas funciones de la misma aplicación. Sin embargo, si una organización fusiona todo
el código fuente diversificado en un solo día (conocido como el ”día de la fusión”), las
tareas resultantes pueden ser tediosas y manuales, y pueden tomar mucho tiempo.

Esto sucede porque, cuando un desarrollador trabaja de forma aislada para imple-
mentar un cambio en una aplicación, existe la posibilidad de que este cambio entre en
conflicto con otros cambios implementados simultáneamente por otros desarrolladores.
La integración continua ayuda a que los desarrolladores fusionen los cambios que in-
troducen en el código para incorporarlos a una división compartida (o rama”) con más
frecuencia, incluso diariamente. Una vez que se fusionan los cambios implementados
2
Intervalo prefijado durante el cual se crea un incremento de producto
3
Metodología para desarrollo de software

11
por un desarrollador en una aplicación, se validan con el desarrollo automático de la
aplicación y la ejecución de distintos niveles de pruebas automatizadas (generalmente,
pruebas de unidad e integración) para verificar que los cambios no hayan dañado la
aplicación.

Esto significa probar todo, desde las clases y el funcionamiento hasta los distintos
módulos que conforman toda la aplicación. Si una prueba automática detecta un con-
flicto entre el código nuevo y el existente, la CI facilita la resolución de esos errores con
frecuencia y rapidez.

4.4. Sistema de integración continua

Para que un sistema de integración continua sea eficiente, hay ciertas prácticas que
debemos llevar a cabo:

Mantener un repositorio de una única fuente

Automatizar las construcciones de un proyecto

Hacer que el proyecto ejecute sus propios exámenes.

Todos los miembros del proyecto hacen commit a una principal todos los dias.

Todos los cometidos a la rama principal ejecutan una compilación

Las construcciones erróneas deben arreglarse inmediatamente.

Realizar la construcción lo más rápido posible

Hacer pruebas en una copia del escenario de producción real

Despliegue continuo

4.5. ¿Qué es la entrega continua?

La entrega continua (CD) lleva el principio de CI un paso más allá según Wallgren, A.
(2016): Es el proceso automatizado de compilación y prueba que extiende a todos los

12
 Figura 4.2: Ciclo de vida de devOps
Fuente: https://www.edureka.co/blog/devops-tools

componentes de la aplicación, incluidos los archivos de configuración, los esquemas

de base de datos y los entornos. Cada vez que se realizan cambios en cualquiera de
estos componentes, el procedimiento de compilación y prueba se realiza (idealmente a
través de una canalización automatizada) para que la compilación resultante se pueda
implementar fácilmente. La compilación resultante no siempre tiene que publicarse en
producción, pero al menos debe implementarse en un entorno (como la organización
por etapas) lo más cercano posible a la producción. Por lo tanto, los propietarios del pro-
ducto pueden estar seguros de que cualquier compilación que pase por este conducto
sea liberado para el público.

Figura 4.3: CICD Fuente: de https://www.edureka.co/blog/devops-tools

13
4.6. Control de versiones

El trabajo del desarrollador es el código. Este código es compartido y almacenado de

forma segura generalmente con uso de herramientas. Llamamos a este tipo de herra-
mienta de control de versión según Typical CI process (source: www.pepgotesting.com)
porque no solo almacena de forma segura el código, y permite a los desarrolladores
compartir el código y colaborar juntos como un equipo en el mismo código, sino también
versiones del código. Eso significa que cada vez que un desarrollador agrega algún có-
digo, no reemplaza la versión anterior, sino que agrega un cambio en el historial. De
esa manera, los desarrolladores pueden desordenar y pueden volver fácilmente a una
versión anterior. También pueden investigar problemas y comprender lo que sucedió
en el código mirando la historia.

Figura 4.4: Proceso de trabajo

Fuente: https://www.edureka.co/blog/devops-tools

4.7. GitFlow

GitFlow es un modelo de ramificación según Scot Chacon(2009), El modelo de Git-

Flow es ideal para una integración continua. La idea es asegurarse de que cada vez
que una rama de función se fusione para desarrollarse, la integración continua com-
prueba que todo está correcto en esta rama principal.
Este control se realiza regularmente. Dependiendo del contexto del proyecto y de la
madurez del equipo, esta comprobación se puede realizar solo una vez al día o, por el
contrario, cada vez que un desarrollador realice un cambio único.

14
 Figura 4.5: git workshop
Fuente: https://fpy.cz/pub/slides/gitworkshop/step1

4.7.1. Ramas

Básicamente, lo que estamos hablando se llama branches en la terminología de

control de versiones. Una de estas branches tiene un significado especial y representa
lo que está en producción, cuál es la última versión actual. todo el código generado
se sube a una de las ramas, a menudo se llama (aunque no siempre) la rama master
para generar el deploy. Cuando los desarrolladores crean una nueva característica, no
trabajan directamente en esta rama la crean en otra diferente donde se interactuara.

Figura 4.6: Creacion de una rama

Fuente: https://jp-lambert.me/git-gitflow-and-continuous-integration-for-
dummies-5e4300148fbf

Ramas principales

El repositorio central tiene dos ramas principales con una vida infinita:

15
 master

develop

Ramas de apoyo

A diferencia de las ramas principales, estas ramas siempre tienen un tiempo de vida
limitado, ya que eventualmente se eliminarán.

Feature branches(Ramas destacadas)

Release branches(Ramas de liberación)

Hotfix branches (Ramas Hotfix)

4.7.2. Merge

Es el término fusionar en la sección anterior a una sola rama, por lo general la rama
nueva se integra al master.

Figura 4.7: Merge Fuente: https://jp-lambert.me/git-gitflow-and-

continuous-integration-for-dummies-5e4300148fbf

16
4.8. Ventajas de la integración continua

La integración continua proporcióna varias ventajas o beneficios en el desarrollo de

software entre las cuales se menciona a continuación:

fácilmente deducible, el nombre que adquiere esta práctica es descriptivo y literal.

Se basa en la comprobación continua del código para poder integrar poco a poco
las mejoras o ir actualizando a diario para obtener un resultado mucho más fiable y
en periodo menor de tiempo. Lo que permite ajustar mejor a los timings propuestos
y evitar las presiones derivadas de última hora por la presión de las entregas.

aptitud a nivel personal. Puesto que estas prácticas se llevan a cabo en proyec-
tos conjuntos, son los propios desarrolladores los que van analizando el código
creado, apoyándose los unos en los otros. Los mismos aprenderan diferentes mé-
todos de integración y se ven obligados a superar día tras día diferentes errores
o fallos encontrados en el código creado. Esto implica fomentar la comunicación
entre el equipo, y hace que sea mucho más enriquecedor tanto a nivel individual
como a nivel de grupo o equipo.

Acelerar la detección de fallas ,versión constante para pruebas, o una primera

fase para poder contrastar la evolución del código de forma que haga posible
detectar los errores a tiempo y poder corregirlos.

A su vez, en todo momento cada miembro del equipo tiene acceso a la versión
final.

La integración continua garantiza unos resultados de calidad y un funcionamiento

correcto del proyecto gracias a su continua supervisión y a la reducción de errores.

Evidentemente todo este proceso de revisiones y correcciones lo más frecuentes

posibles, forman parte de una automatización que se desarrolla para facilitar la
comunicación entre el equipo y la evolución del proyecto el cula disminuye el lapso
de tiempo dedicado a depurar errores.

Evitar la espera para averiguar si un código funciona para esto el monitoreo de

las métricas más relevantes del proyecto, de forma que se pueda tener presente
en todo momento la calidad del mismo. Esto a la larga, llevará a un buen código
sin necesidad de modificaciones una vez llevado a la última fase, puesto que se
logra optimizar a medida que se lo construye.

17
 En resumen, los beneficios de la integración continua consisten en “resolver pro-
blemas rápidamente”. Dado que el software es integrado frecuentemente, cuando se
encuentra un error típicamente no es necesario retroceder mucho para descubrir don-
de se introdujo la falla. En comparación, cuando un equipo no sigue una estrategia de
integración continua los periodos entre integración son largos y la base de código es
muy distinta entre cada integración por lo que cuando se encuentran errores hay que
revisar mucho más código, lo cual requiere un mayor tiempo y esfuerzo. En palabras
de Fowler, “la integración continua no elimina los defectos, pero si hace que sea mucho
más fácil encontrarlos y corregirlos”.

4.9. Desventajas de la integración continua

Complejidad en manejo de las herramientas, esto implica un coste en la capacita-

ción del personal o del equipo dado esto conlleva tiempo adicional en el desarrollo
del mismo.

Costes de hardware, para ello es necesario un conjunto de máquinas que alber-

garan las diversas herramientas para la integración continua : repositorio ,auto-
matización, entornos ,etc.

Tiempo de configuración inicial, en un entorno en el que se diseñan, desarrollan

y documentan adecuadamente los casos de prueba, nos queda invertir el tiempo
oportuno en la configuración de la herramientas de integración continua.

Cambio de procesos habituales.

Precisa de servidores y entornos adicionales.

Podría derivar en demoras cuando varios desarrolladores intentan integrar sus

códigos al mismo tiempo.

18
 5 PASOS A REALIZAR PARA INTEGRACIÓN
CONTINUA

Existen elementos indispensables según Adanza, F. (2016) los implicados son parte
de la integración continua y es como parte de los requerimientos que se necesita para
la CI.

5.1. Un único código fuente

Según Fowler (2006) trata de uno de los factores más importantes, ya que todos
los integrantes del equipo deberán utilizar la misma herramienta, es decir, el mismo
repositorio, cuando trabajen en el código. Y esto no solo se aplica al código fuente.
Para que funcionen las aplicaciones, se necesitan otros elementos como, por ejemplo,
bases de datos, que también deberán estar contenidos en el mismo lugar. Por ello, Mar-
tin Fowler recomienda construir un repositorio de tal forma que cualquier ingeniero que
se incorpore al proyecto con un equipo nuevo encuentre todos los archivos necesarios
en un único lugar.

5.2. Automatizar la compilación del proyecto

La obtención de un proyecto funcional a partir de un código fuente implica la compi-

lación del mismo, actualizar bases de datos y mover ficheros de un sitio a otro. Todas
estas tareas pueden automatizarse y debería ser posible ejecutar la compilación con
un único comando.

19
5.3. Sistemas que realizan sus propias pruebas

Un equipo podrá beneficiarse de aún más automatización y rapidez a través de la

integración continua si se incorporan mecanismos de prueba en el proceso de compila-
ción (“build”)1 . Al igual que la propia compilación, las pruebas podrán llevarse a cabo en
poco tiempo, y lo ideal será implementar un plan completo de mecanismos de prueba.

5.4. Integración diaria

Un proceso de “continuous integration” 2 funcionará únicamente si todos los miem-

bros del equipo respetan el sistema. En el momento en que algún miembro del equipo
no integre su código en la línea principal, el resto de compañeros partirá de una premi-
sa falsa.
Todos los desarrolladores asumen que trabajan en un sistema estable, pero si alguien
tarda más de un día en integrar su código y continúa trabajando en él, al final la bús-
queda de errores podría convertirse en un verdadero problema.
Asimismo,la comunicación también es un factor importante en la integración continua,
ya que, si los desarrolladores se mantienen al tanto, las pequeñas dificultades podrán
aclararse con mayor rapidez.

5.5. Linea principal operativa

El código de la línea principal deberá probarse continuamente y encontrarse siem-

pre operativo, por lo que los desarrolladores deberán construir el proyecto aquí y no
solo en su copia local. En este contexto, todos deberán preocuparse también de que
sus aportaciones sean válidas y de que su funcionamiento sea correcto, de modo que
todos tendrán que comprobar el código y el build. Si aparece algún fallo, tendrán que
solventarlo y garantizar que el código no contiene errores.

1
Construir
2
Integración Continua

20
5.6. Reparación inmediata

Lo más importante de la integración continua es que no quede ninguna versión

defectuosa en la línea principal, lo que implica que la solución de los fallos no podrá
posponerse. En palabras de Martin Fowler, no existe ningún problema si los builds no
funcionan y el código debe cambiarse, pero el sistema requiere que la reparación se
lleve a cabo de inmediato. Todos los desarrolladores deben poder partir del hecho de
que el código de la línea principal funciona correctamente, de lo contrario, podrían estar
trabajando sobre un código defectuoso que acabará desencadenando una oleada de
fallos.

5.7. Integración rápida

La integración completa del proyecto (incluida la fase de prueba) debería realizarse

lo más rápido posible. La programación extrema (extreme programming, XP) 3 prevé
solo 10 minutos para esto. Puesto que un desarrollador debe realizar varias integracio-
nes diarias, si no se establecieran mecanismos para acelerar el proceso se perdería
una gran cantidad de tiempo. Para que no se demore demasiado, debe descartarse la
idea de realizar todas las pruebas posibles directamente y aplicarse en lugar de ello un
sistema de dos fases: en la primera fase, se realizan pruebas en las que la compila-
ción del proyecto pueda ser rápida. La segunda fase durará varias horas y en ella se
llevarán a cabo pruebas más exhaustivas.

5.8. Pruebas en una replica del entorno de producción

Las pruebas deberán realizarse en un entorno seguro y con una configuración exac-
tamente igual que la del entorno de producción. Bajo determinadas circunstancias, esto
podría resultar muy costoso, pero la virtualización de los equipos hará que el factor de
los costes se reduzca.

3
Metodología de programación

21
5.9. Accesibilidad

Todos los involucrados en el desarrollo de un determinado software deberían poder

obtener fácilmente el último ejecutable del programa y ejecutarlo. La implementación de
este aspecto es relativamente sencilla, ya que la integración continua exige que todos
los archivos se encuentren en un único repositorio que todos conocen. De este modo,
se puede comenzar a realizar pruebas adicionales en el proceso de programación, los
accionistas pueden utilizar archivos ejecutables con fines demostrativos y los directores
de calidad pueden examinar las cifras.

5.10. Buena comunicación

No solo resulta importante que todos los implicados tengan acceso al código fuente
y puedan ejecutar el archivo, sino que, además, debe quedar constancia de quién ha
realizado qué modificación. Asimismo, los desarrolladores deben informar cuando se
encuentren en un proceso de compilación, para lo que algunos equipos utilizan ele-
mentos visuales que indican que se está trabajando en la integración.

5.11. Despliegue automatizado

Por último, ha de automatizar el despliegue del software. Para llevar a cabo la in-
tegración continua se deben mover ejecutables entre múltiples entornos, lo que puede
requerir una gran cantidad de tiempo. Por ello, será mejor hacerlo de forma automática
utilizando scripts 4 que faciliten el despliegue de aplicaciones entre entornos.

4
Texto que consta de una serie de instrucciones que deben ejecutarse

22
 6 HERRAMIENTAS PARA CREAR UN ENTORNO
DE INTEGRACIÓN CONTINUA

Las herramientas de integración continua se pueden integrar unas con otras para
generar un flujo de trabajo.

Figura 6.1: Herramientas más utilizadas

Fuente: https://www.edureka.co/blog/devops-tools

6.1. Jenkins

Jenkins en Jenkins 1.396 released es un servidor de integración continua dirigido

por CloudBees y escrito en Java, el cual deriva del proyecto Hudson. Es distribuido bajo
licencia MIT, y permite llevar a cabo las siguientes acciones:

Construcción continua y pruebas automatizadas de proyectos software.

Monitorizá de la ejecución de servicios externos.

23
 Suele ser usado para proyectos escritos en Java, pero también puede trabajar con
otros lenguajes como C, Python, Ruby, etc., además permite usar un gran número de
herramientas de construcción, tales como Ant, Maven, Kundo, Gradle, etc. El servi-
dor de Jenkins obtiene la información derivada de los fallos de construcción y permite
enviar, a traves de su sistema de notificaciones, esta información a los miembros en-
cargados del proyecto.
Ademas permite usar una gran cantidad de SCMs, algunos de ellos son CVS, Git,
Bazaar, Integrity, Mercurial, Perforce, Subversion, Vault, etc. Para extender su funciona-
lidad tiene un gran numero de plugins. Estos plugins permiten integrar este servidor con
otras herramientas como IceScrum, más herramientas de construcción y una gran can-
tidad de herramientas de pruebas como Selenium, JMeter, xUnit, MSTest TRX, JSUnit,
etc. Por otro lado una de las extensiones de Jenkins mas llamativas para el presente
trabajo, es el plugin delivery-pipeline-plugin.
Se puede notar que Jenkins constituye uno de los servidores de integración continua
mas completos, que destaca debido a su alta funcionalidad, integración con muchos
entornos y herramientas, una importante extensibilidad, que como se ha descrito en
el documento se lleva a cabo mediante plugins y por la cantidad de documentación
que existe de esta herramienta. A su vez este servidor se ve avalado por una gran
comunidad.

6.1.1. Integración continua con jenkins

Para empezar a trabajar con Jenkins, lo primero de todo es disponer de un servidor

propio o un equipo. En este caso, se ha utilizado una maquina local, Dicho maquina
funciona con sistema operativo OS donde se instalara Docker y Docker-compose, ya
que se necesita un contenedor Docker exclusivo para instalar Jenkins. A continuación,
debemos ejecutar el siguiente comando en la consola de la maquina:
docker build -t jenkis - elvikito .

El comando introducido lo que realizara es construir una imagen desde del archivo
“Dockerfile”.
docker run -d -p 80:8080 -p 50000:50000 jenkis - elvikito

Gracias a este comando, se ha creado un nuevo contenedor llamado jenkis-elvikito,

cuyo puerto 8080 está disponible en el puerto 80 de nuestra maquina. Dicho comando
nos da una respuesta con un código alfa-numérico, que hay que guardar, ya que nos

24
servirá para crear la cuenta de usuario de Jenkins.
Para acceder al contenedor jenkis-elvikito, simplemente hay que abrir un navegador
web y navegar localmente o haciendo uso de su aplicación web (Kunja, 2017):
http :// localhost :80 o http ://127.0.0.1:80

La primera vez que se accede mediante la url, debe crear la cuenta de administrador,
para poder acceder a la gestión de tareas dentro del propio Jenkins.

Figura 6.2: Ventana inicio de jenkins

Fuente: elaboración propia

Figura 6.3: Pagina principal jenkins

Fuente: elaboración propia

25
 Figura 6.4: Ventana de dashboard de jenkins
Fuente: elaboración propia

Pasos para crear una tarea

1. General

Figura 6.5: Paso general de la creación de la tarea

Fuente: elaboración propia

En este paso se establecen el nombre y se define el tipo de tarea. Una vez in-
troducido en nombre y se selecciona el tipo de tarea se presiona ok y la tarea se
genera para poder configurar posteriormente.

26
2. Source Code Management

Figura 6.6: Paso Source Code Management de la tarea

Fuente: elaboración propia

En este paso se establece GitLab(2019) como sistema de control de versiones la

que se usa para alojar a un repositorio a controlar y se indica que esta tarea en
la rama master.

3. Build Triggers

Figura 6.7: Paso Build Triggers de la tarea

Fuente: elaboración propia

27
 En este paso se establece que la ejecución de la build empezará cada dia a las
8 am obteniendo el código desde GitLab de la rama master. Aquí es donde se
programa la ejecución de la tarea y que sea periódica, debe definirse el periodo
de ejecución de lo contrario no se ejecutará de manera periodica

4. Build Environment

Figura 6.8: Paso Build Environment de la tarea

Fuente: elaboración propia

En este paso se establece que la ejecución contenga variables que puedan utili-
zar, por ejemplo alguna ruta de un archivo.

5. Build

28
 Figura 6.9: Paso Build de la tarea
Fuente: elaboración propia

En este paso se establece el comando o instrucción que deberá seguir la tarea,

dicha instrucción es la que se ejecutara periódicamente.

6. Build Settings

Figura 6.10: Paso Build Triggers de la tarea

Fuente: elaboración propia

En este paso se establece que la ejecución contenga algunas configuraciones

adicionales para la ejecución.

7. Logs

29
 Figura 6.11: Los Logs generados por la tarea
Fuente: elaboración propia

Este paso es la que una vez ejecutado se puede visualizar los mensajes de la
ejecución, son los comandos, instrucciones que recibio la tarea.

6.2. GitLab

En GitLab(2019) se denota como un herramienta muy completa, una de las necesi-

dades de los proyectos es tener teses y que estos se ejecuten con cada commit para
asegurar que los cambios no introducen errores en las funcionalidades cubiertas por
los teses, esto es la integración continua. La entrega inmediata es una vez que los te-
ses se han ejecutado correctamente hacer el despliegue en los servidores de forma
pasa el tiempo mínimo entre que una funcionalidad está desarrollada y esta se puede
utilizar.
GitLab proporciona integración continua (Continuos Integration, CI) y entrega conti-
nua (Continuos Delivery, CD) sin necesidad de una herramienta externa más especia-
lizada como es Jenkins.

30
 Figura 6.12: GitLab y jenkins
Fuente https://www.edureka.co/blog/devops-tools

6.3. SonarQube

Sonarqube(2019) es una herramienta de análisis estático que evalúa nuestro códi-

go fuente. Se trata de software libre que empleo diversos plugins de análisis estático
de código fuente como Checkstyle, PMD o FindBugs para obtener métricas que pue-
den ayudar a mejorar la calidad del código de un desarrollo software y entender que
problemas tenemos en nuestro código fuente
Entre sus funciones están la de dar métricas acerca de código duplicado, prue-
bas unitarias, cobertura del código, potenciales errores o estándares. Inicialmente, la
herramienta estaba pensada para Java pero acepta extensiones para otros lenguajes.
En nuestro caso, lo estamos usando para analizar proyectos desarrollados en Symfony.
Además, se integra correctamente con herramientas de integración continua como Jen-
kins, por lo que podemos automatizar este análisis cada vez que un desarrollador sube
código.

¿Qué tipo de problemas podemos resolver? Un análisis estático del código no

es suficiente, necesitamos también otro tipo de herramientas como los tests unitarios
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:

Problemas de Diseño: Podemos detectar problemas en el diseño y arquitectura

31
del software analizando las dependencias entre las clases del proyecto. Esto nos per-
mite actuar a tiempo frente a crear un enmarañado de clases totalmente acopladas y
difícilmente reutilizables.
Duplicidad de Código: Sonarqube nos proporciona métricas de código duplicado, pu-
diendo detectar partes de nuestro software se asemejan, pudiendo así tomar decisiones
como desacoplar componentes o aplicar técnicas de refactoring utilizando el poliformis-
mo, la herencia y la reutilización de componentes.
Detección de Vulnerabilidades: Sonarqube cuenta con una base de datos de codes-
mells 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. Standard de codificación: Avisándonos de partes del código que no cum-
plan con el PSR o incluyan malas prácticas a la hora de definir constantes, variables,
llamadas a métodos estáticos.
Monitorización de Cobertura: En nuestro caso también lo usamos para poder moni-
torizar si la cobertura de los tests 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 tests del proyecto.

Figura 6.13: SonarQube Elaboración propia

32
6.4. Nexus

Nexus(2019) puede analizar los componentes utilizados en su desarrollo de softwa-

re para las características de seguridad y licencia. Cuando se integra con un servidor
de integración continua, se convierte en un análisis dinámico que se lleva a cabo de
forma regular y se produce potencialmente con cada compilación que se ejecuta en el
servidor.
Todas nuestras herramientas de CI le permiten realizar un análisis completo de se-
guridad y licencia de los artefactos producidos por la compilación configurada respal-
dada por su servidor Nexus IQ. Le proporcionará acceso al informe de análisis.

6.5. Apache Maven

Apache Maven (2019) es una de las herramientas más usadas en la gestión y cons-
trucción de proyectos software Java creado en 2002 por Jason van Zyl, y cuya mayoría
de ellos se encuentra en Apache Ant, make, PEAR, CPAN, etc. Esta herramienta se ba-
sa fundamentalmente en la estructura del proyecto, el software que se va a gestionar y
un archivo que describe todas las propiedades del proyecto denominado POM (Project
Object Model). Este último archivo está escrito en formato XML y contiene información
como un identificador único del proyecto, licencia, miembros del proyecto, dependen-
cias del proyecto, repositorios remotos de artefactos Maven (los que se pueden obtener
las dependencias requeridas por el proyecto), plugins que aplicar añadir al proyecto y
muchos otros. Se puede definir un ciclo de vida estricto para una aplicación de ma-
nera que la ejecución de una fase de este ciclo implica la ejecución de todas las fases
anteriores. De manera ordenada las fases que definen el ciclo de vida del proyecto son:

Compilar: Compilar los fuentes .java generando los registros .class

Test: Ejecuta test.

Paquete: Crear un paquete con los números compilados en el formato especifi-

cado en el POM.

Instalar: Copia el paquete generado un directorio local de servidores para que

pueda ser usado de nuevo en otro proyecto.

33
 Implementar: Copia el paquete generado en un servidor remoto para que pueda
ser usado de nuevo por cualquier otro proyecto.

Se ha elegido esta herramienta de la construcción de proyectos estandarizadas del

ciclo de la vida de los proveedores, el sistema de la gestión de las dependencias en los
repositorios y la integración con un gran número de herramientas y marcos, lo que va
a permitir que se realice las pruebas de manera automatizada.

6.6. Docker

Docker(2019) es una plataforma de software que le permite crear, probar e imple-

mentar aplicaciones rápidamente. Docker empaqueta software en unidades estandari-
zadas llamadas contenedores que incluyen todo lo necesario para que el software se
ejecute, incluidas bibliotecas, herramientas de sistema, código y tiempo de ejecución.
Con Docker, puede implementar y ajustar la escala de aplicaciones rápidamente en
cualquier entorno con la certeza de saber que su código se ejecutará.

Figura 6.14: Docker containers obtenido de

https://www.edureka.co/blog/devops-tools

¿Cómo funciona Docker? Docker le proporciona una manera estándar de ejecutar

su código. Docker es un sistema operativo para contenedores. De manera similar a có-
mo una máquina virtual virtualiza (elimina la necesidad de administrar directamente) el
hardware del servidor, los contenedores virtualizan el sistema operativo de un servidor.
Docker se instala en cada servidor y proporciona comandos sencillos que puede utilizar
para crear, iniciar o detener contenedores.

34
6.6.1. Comandos básicos

docker pull jenkins Descarga la imagen oficial de Jenkins que se encuentra en Doc-
kerHub. ventana acoplable ejecutar un nuevo contenedor. Este comando tiene diferen-
tes parámetros de entrada:

-rm Borra el contenedor cuando terminemos de usarlo.

-it Conecta el contenedor a la terminal de Linux.

-name cont Pone el nombre cont al contenedor.

-p24601:80 Mapea el puerto 24601 de la máquina al puerto 80 del contenedor.

-v /dev: /code Monta el directorio /dev como el directorio /code dentro del conte-
nedor.

jenkins:1.2 Instancia la versión 1.2 de Jenkins (si ponemos latest como versión,
descarga la más reciente).

./script.sh Ejecuta este comando al iniciar el contenedor. docker start mycont

Inicia el contenedor mycont.

docker stop mycont Para el contenedor mycont.

docker kill mycont Mata el contenedor mycont.

docker images Muestra las imágenes disponibles en local.

docker rmi myimag Borra la imagen myimag en local.

docker ps -a Muestra todos los contenedores creados en local.

docker rm mycont Borra el contenedor mycont en local.

docker login Hace login en DockerHub y guarda nuestras credenciales.

docker push myuser/myapp:1.4 Sube la imagen a DockerHub con el tag “myu-

se/myapp:1.4”.

35
 7 CONCLUCIÓN

En concepto la integración continua es una forma de desarrollo de software que me-

jora el proceso de desarrollo y la puesta en producción del producto a desarrollar, por
medio de herramientas automatización y mejora continua donde existen mas ventajas
que desventajas o inconvenientes.

Tener una organización en la que la integración continua esta consolidada, como

una buena practica ahora bien si pasa lo contrario, la recomendación debería ir paso a
paso y dejar que la organización se empaque de las diversas mejores practicas, y se
engrasen los engranajes, de la misma, dicho esto si la organización lo implementa de
una manera apresurada podría llevar al fracaso.

Podemos decir que la integración continua y la entrega continua son conceptos

bastante simples. No hay magia negra ni ciencia espacial en ambos casos de uso. La
elección de herramientas y enfoques para lograrlo depende en gran medida de la natu-
raleza del software que estamos creando. Al diseñar software, de acuerdo a las buenas
practicas investigadas es una buena idea tener en cuenta la integración continua y la
entrega continua para maximizar la productividad del equipo y tener una entrega rápida
y robusta.
Al optar por esta arquitectura de micro servicios se desarrolla el producto de manera
diferente y controlada ayudado por la integración continua, debido a que el proyecto
contempla la realización de test o despliegues del producto, se tiene la seguridad sobre
el producto que se desarrolla.

36
Referencias Bibliográficas
Martin Fowler (2006, 1 de Mayo). Continuous Integration. Disponible en
https://martinfowler.com/articles/continuousIntegration.html

Jez Humble and David Farley (2011). Continuous Delivery. Disponible en

https://martinfowler.com/books/continuousDelivery.html

Jgarzas (2014, 18 de octubre). Ph.D. en informática, Postdoctorate en la Carnegie

Mellon (EE.UU) e Ingeniero en Informática.
Sitio web: https://www.javiergarzas.com/2014/09/libro-integracion-continua.html

Gómez-Luna, E., & Fernando-Navas, D., & Aponte-Mayor, G., & Betancourt-Buitrago,
L. (2014). Metodología para la revisión bibliográfica y la gestión de información de
temas científicos, atraves de su estructuración y sistematización. Dyna, 81 (184),
158-163.

Carlos Blé Jurado(2016) Diseño Ágil con TDD.

Adanza, F. (2016), Implementing continuous delivery: Jenkins or Bamboo,

Disponible en: https://www.getzephyr.com/insights/implementing-
continuous-delivery-jenkins-or-bamboo(04 Junio 2017)

Atlassian, (n.d.), Understanding the Bamboo CI Server, Disponible en:

https://confluence.atlassian.com/bamboo/understanding
-the-bamboo-ci-server289277285.html (04 Junio 2017)

Stafford, J. (n.d.), Why automated continuous integration is a must for microservi-

ces success Web:,
http://searchmicroservices.techtarget.com/feature/
Why-automated-continuousintegration-is-a-must-for-microservices-success (03 Ju-
nio 2017)

Sneha Kunja, S. (2017), What is Jenkins?, Disponible en:

https://vmokshagroup.com/blog/what-is-jenkins/ (04 Junio 2017)

Wallgren, A. (2016), Continuous Delivery and Release Automation for Microservi-

ces, Disponible en:
http://electric-cloud.com/blog/2016/01/continuous-delivery-and-release-automation-
formicroservices/ (03 Junio 2017)

37
P. M. Duvall, S. Matyas, and A. Glover (2007) Continuous integration: improving
software quality
and reducing risk. Pearson Education.

Typical CI process, (04 Junio 2019) Disponible: www.pepgotesting.com

Scot Chacon. Pro Git. (2009).

Fowler, M., Beck, K., Brant, and J. (2009) Refactoring: Improving the Design of
Existing Code.

Jenkins 1.396 released, The first release of Jenkins is posted, Kohsuke Kawagu-
chi.

Gitlab (2019). Disponible en https://about.gitlab.com/product/continuous-integration/

Sonarqube (2019). Disponible en https://docs.sonarqube.org/latest/

Nexus (2019). Disponible en https://help.sonatype.com/integrations/nexus-and-

continuous-integration

Apache Maven (2019). Disponible en https://maven.apache.org/guides/index.html

Docker (2019). Disponible en https://docs.docker.com/

38
8 ANEXO I: DOCKERFILE JENKINS

8.1. Ejemplo Dockerfile

FROM jenkins / jenkins :lts - alpine

MAINTAINER elvikito

ENV DEBIAN_FRONTEND noninteractive

ENV maven_version 3.3.9

ENV MAVEN_HOME / opt / maven

USER root
RUN apk update
RUN apk add wget curl openssh - server nano sudo

RUN echo " alias nano =' export TERM = xterm && nano '" >> / root /. bashrc

RUN echo " jenkins ALL = NOPASSWD : ALL " >> / etc / sudoers

ARG maven_filename =" apache - maven -${ maven_version }- bin . tar .gz"
ARG maven_filemd5 =" 516923 b3955b6035ba6b0a5b031fbd8b "
ARG maven_url =" http :// archive . apache . org / dist / maven /\
maven -3/ ${ maven_version }/ binaries /${ maven_filename }"
ARG maven_tmp ="/ tmp /${ maven_filename }"

39
RUN wget --no - verbose -O ${ maven_tmp } ${ maven_url }
RUN echo "${ maven_filemd5 } ${ maven_tmp }" | md5sum -c

# install maven
RUN tar xzf ${ maven_tmp } -C / opt / \
&& ln -s / opt / apache - maven -${ maven_version } ${ MAVEN_HOME } \
&& ln -s ${ MAVEN_HOME }/ bin / mvn / usr / local / bin

ENV PATH ${ MAVEN_HOME }/ bin : $PATH

RUN rm -rf / var / lib / apt / lists /* / tmp /* \

/ var / tmp /* / usr / share / man / / usr / share / man /_*

USER jenkins

RUN echo " alias nano =' export TERM = xterm && nano '" \
>> ${ JENKINS_HOME }/. bash_aliases

RUN mvn -- version

40
8.2. Micro servicios

Figura 8.1: Implementación con jenkins Fuente:

https://integraconsultores.es/servicios/desarrollo-ad-hod/saber-
mas/attachment/integracion_continua

41
Figura 8.2: Arquitectura implementada Fuente http://oa.upm.es/37313/

42