Escolar Documentos
Profissional Documentos
Cultura Documentos
Cochabamba – Bolivia
2018
Dedico esta monografía a mi familia por el
apoyo en estos meses de estudio y por la paciencia
que tuvieron durante el tiempo de estudio.
2
Tabla de Contenido
Resúmen 6
Introducción 7
1. Generalidades 7
2. Metodología 9
3. Marco Teórico 9
3
5. Resultados 27
6. Conclusiones 27
7. Diccionario de términos 29
8. Bibliografía 29
4
Lista de Figuras
5
RESÚMEN
Integración Continua (CI) forma parte de las metodologías ágiles, su trabajo es facilitar a
los desarrolladores la integración del código entre el equipo, permite la creación del código en
tiempos muy frecuentes, para hacer que esto sea posible y fácil, debe existir un minucioso
control de calidad de software.
Llevar a producción un software o una nueva versión es una tarea delicada, para que
esto sea posible debemos usar un sistema de automatización que sea capaz de construir el
software y desplegarlo en servidores, pero que sólo permita esta puesta en producción cuando
las pruebas han sido ejecutadas exitosamente.
Las Pruebas Continuas ayudan a mitigar el nivel de riesgo introducido por los cambios
creados con las modificaciones realizadas durante un sprint de desarrollo, es el ejecutar de
manera constante, selectiva o completa las pruebas de software automatizadas que se tengan
para las diferentes fases del ciclo de vida del Software. Se pretende identificar la contribución
de estas pruebas en el ciclo de Integración Continua y Entrega Continua.
6
INTRODUCCIÓN
Según la definición de Martin Fowler (2006): “La integración continua es una práctica de
desarrollo de software en la cual los miembros de un equipo integran su trabajo frecuentemente,
como mínimo de forma diaria. Cada integración se verifica mediante una herramienta de
construcción automática para detectar los errores de integración tan pronto como sea posible.
Muchos equipos creen que este enfoque lleva a una reducción significativa de los problemas de
integración y permite a un equipo desarrollar software cohesivo de forma más rápida.”
Entrega continua (CD) busca poner el software en producción lo mas antes posible y de manera
regular; ya sea diaria, semanal o hasta mensualmente y no esperar largos periodos para
entregar al cliente los cambios desarrollados por el equipo de desarrollo.
1. GENERALIDADES
La metodología Ágil surge a principios del año 2000, con la intención de corregir
algunas malas prácticas en la gestión de proyectos y al día de hoy, es un modelo estándar en
muchas empresas internacionales.
7
1. Valorar a los individuos y las relaciones sociales por encima de los procesos y las
herramientas.
Agile es una metodología que rompe con los tradicionales proyectos de planificación
lineal, que además de extenderse mucho en el tiempo y ser poco productivos, no tenían en
cuenta las posibles novedades y modificaciones, hasta que se entregaba el producto al cliente.
Este tipo de planificación permitía poca flexibilidad ante los cambios y la introducción de
arreglos y modificaciones poco efectivas.
Martin Fowler publicó en el 2005 un artículo sobre Integración Continua. En este artículo
Fowler explicaba que la Integración Continua tenía un beneficio directo en los proyectos
software reduciendo el riesgo y tuvo el efecto añadido de ayudar a que se difundiera con más
fuerza.
8
construida para este propósito, podemos pensar que fue Cruise Control que surgió en el 2001
como servidor de código extensible. Se trata de una herramienta gratuita y código abierto
pensada para realizar construcciones de código automáticos usando Ant o Maven. Funcionaba
a través de plugins que extendían su funcionalidad. Existe una herramienta para .NET similar
denominada Cruisecontrol.NET que aparecio el 2003 con su versión 0.3.1 pero no es hasta
2005 que aparece la primera versión 1.0 estable. Es decir, que la integración continua basada
en herramientas específicas, tampoco es tan lejano.
Cuando más adelante Oracle compró Sun, este declaró que quería registrar el nombre
de Hudson y desarrollar una versión comercial. Esto enfadó mucho a la comunidad de
desarrollo de Hudson, la cual decidió junto con Kawaguchi hacer una copia del código de
Hudson y llamarlo Jenkins en 2011. Al final Oracle se da por vencido y en 2012 dona Hudson a
la fundación Eclipse.
2. METODOLOGÍA
3. MARCO TEÓRICO
La Integración Continua (CI) es una práctica de desarrollo que hace un llamado a los
equipos de desarrollo para garantizar que se realice una implementación y pruebas posteriores
9
para cada cambio de código realizado en un programa de software. Este concepto estaba
destinado a eliminar el problema de encontrar las incidencias tardías de problemas en el ciclo
de vida de la implementación. La integración continua es un proceso en el que todo el trabajo
de desarrollo se integra lo antes posible. Los módulos resultantes son creados y probados
automáticamente. Este proceso permite identificar errores lo antes posible.
10
Figura 1. Integración continua
Entonces entra Jenkins que es una herramienta de integración continua, como sistema
de automatización que puede realizar las tareas necesarias para asegurar la calidad del
software y facilitar su despliegue y construcción. Las tareas que Jenkins puede desempeñar son
las siguientes:
● Revisar las métricas de calidad del software establecidas por el equipo de trabajo.
11
● Notificar debidamente a los desarrolladores o al equipo de control de la calidad
cuando se encuentra cualquier tipo de error.
Un proceso de Entrega Continua (CD) deberá lanzar los nuevos cambios de manera
frecuente y rutinaria. Los equipos continúan con las tareas diarias de desarrollo con la
confianza de que pueden mandar a producción un lanzamiento de calidad.
Se considera que la entrega continua es atractiva porque automatiza todos los pasos que van
desde la integración del código en el repositorio base, hasta la liberación de cambios totalmente
probados y funcionalmente adecuados.
12
Figura 2. Entrega Continua
Naik Vishal (2016, Enero 11). Architecting for Continuous Delivery. Recuperado de
https://www.thoughtworks.com/insights/blog/architecting-continuous-delivery
Beneficios:
13
forma automática la puesta en producción una vez que se cubren todos los criterios definidos
para la entrada en Producción para una aplicación.
Esta práctica de igual forma ofrece la máxima flexibilidad ya que permite desarrollar
cualquier necesidad de forma independiente para posteriormente integrar con otras
funcionalidades, validar el código, desplegar en los distintos entornos intermedios, realizar las
pruebas y finalmente implantar en Producción, poniendo en manos de los usuarios finales en el
menor tiempo posible y con la mayor calidad las nuevas funcionalidades implementadas y
garantizando las funcionalidades anteriores. Véase la figura 3.
14
La entrega continua se describe como una publicación automatizada del lanzamiento
del sistema a producción en cualquier entorno, para esto se requiere testear cualquier cambio y
esto se ejecutara de manera automática. Véase Figura 4.
Fergon, D. (2017, Septiembre 5). De la nada al "Todo Continuo" y del Scrum más canónico al Kanban
con #NoEstimates. Disponible en
http://davidfergon.github.io/2015-06-16-de-la-nada-al-todo-continuo-de-scrum-a-kanban-y-noestimates
DevOps no es una profesión, no existen ni perfiles DevOps, sino “ingenieros de sistemas con
capacidades específicas para integrarse en equipos DevOps”.
15
3.6 Tipos de pruebas
Pruebas no funcionales:
- Pruebas de compatibilidad.
- Pruebas de localización.
16
- Pruebas de confiabilidad.
- Pruebas de estrés.
- Pruebas de usabilidad.
- Pruebas de conformidad.
Las pruebas de Software Estructurales son casos de prueba que derivan a partir del
conocimiento de la implementación del software, se denomina pruebas de «caja blanca».
17
Usando casos de prueba ya automatizados es posible ejecutarlos tantas veces como se
requiera y la intervención humana no es es requerida.
- Se pueden correr los casos de prueba sin atención o intervención de una persona.
Puede correr durante la noche.
Mejores prácticas:
● Automatizar la construcción.
● Notificaciones instantáneas.
18
Las pruebas continuas son el proceso de ejecutar pruebas automatizadas como parte
del proceso de entrega de la aplicación con el objetivo de obtener retroalimentación de la nueva
versión de la aplicación lo más antes posible.
Las pruebas continuas van más allá de la automatización y abarcan todas las prácticas,
incluidas las herramientas y el cambio cultural, que ayudan a mitigar los riesgos antes de pasar
a las siguientes etapas del ciclo de vida de desarrollo de software.
Las prácticas de prueba que son manuales tienen que perfeccionarse para que sean
continuas. Es por esto que existe la necesidad de ejecutar pruebas continuas, de esta forma,
cada vez que llegue una compilación nueva con correcciones de errores o nuevas
características para la aplicación, se ejecutarán los conjuntos de pruebas de regresión, lo que
conducirá a pruebas continuas y en función de los errores informados, se puede decidir si se
publicará o no.
Las pruebas unitarias durante la fase de Integración continua no pueden detectar todos
los errores. La lógica empresarial, los problemas de diseño son errores que dichas pruebas no
van a detectar, por eso necesitamos un control de calidad o un entorno intermedio para las
pruebas.
19
Figura 5. Flujo de contribucion del control de calidad
Lee, James (2018, July 5). The Saga of CI/CD and DevOps. Disponible en https://www.level-up.one/saga-
ci-cd-devops/
20
Una prueba unitaria es la forma de comprobar el correcto funcionamiento de un módulo
de código. Nos permite comprobar que cada módulo de nuestro sistema funciona correctamente
por separado.
- Para el sistema desarrollado se han ejecutado pruebas unitarias simples usando Junit
que es un entorno que permite ejecutar tests de clases Java.
● Módulo de Reportes.
- Base de datos
- Se ejecutó test cases automatizados para cada módulo, a continuación se muestran los
test cases ejecutados, véase en la Figura 7.
21
Figura 7. Casos de prueba ejecutados
La lista descrita contiene las herramientas que se pueden usar en distintos tipos de pruebas:
Algunas pruebas que se implementaron para la aplicación de la Constructora son las siguientes.
Véase la Figura 8:
22
Figura 8. Pruebas unitarias desarrolladas
JUnit: esta misma herramienta puede ser usada para las pruebas de integración.
- Cada base de datos probada debe ser capaz de realizar esta prueba simple, insertar los
registros generados y leerlos, ordenados por sus claves.
Selenium:
Cucumber:
23
Estas descripciones funcionales de los casos de prueba se escriben en un lenguaje específico y
legible llamado "Gherkin”, el cual sirve como documentación al desarrollo y para las pruebas
automatizadas.
24
4.5 Roles del ingeniero de calidad
Intentemos listar las actividades que puede llegar a estar bajo el cargo de un Ingeniero
de Calidad. Seguro que esta lista se puede ampliar según el producto que se esté
desarrollando, el tamaño de empresa, contexto de la aplicación, etc.:
● Definir plan y estrategia de calidad: Qué hacer y qué no de acuerdo a los objetivos
y riesgos asociados al contexto. Cómo hacerlo, con qué herramientas, de acuerdo a
las restricciones de presupuesto, etc.
● Pruebas funcionales: Deberá poder probar un sistema con un ojo crítico, en busca
de errores. Existen muchas técnicas de diseño de casos de prueba, y para poder
organizar y planificar adecuadamente deberá manejar la prueba exploratoria con
confianza.
25
● Entender y manejar el gestionador de versiones: Es fundamental que las pruebas
esten alineadas con el desarrollo y un punto de contacto muy relevante es la forma
en la que se manejan las versiones del código, las distintas ramas y asociado a esto,
los distintos ambientes. El código de pruebas deberá ser tratado como parte del
código del sistema y para eso se deberán utilizar las mismas herramientas que un
desarrollador y la misma metodología de gestión de versiones.
● Las pruebas continuas esperan un entorno de prueba estable con datos de prueba
válidos. Este debería estar disponible para cada ejecución de prueba.
● Las pruebas continuas brindan retroalimentación procesable apropiada para cada etapa
del flujo de entrega.
● Las pruebas continuas incluyen pruebas de extremo a extremo que evalúan de forma
realista la experiencia del usuario final en todas las tecnologías asociadas.
● Las pruebas continuas deben ser lo suficientemente amplias como para detectar
cuándo una aplicación cambia inadvertidamente la funcionalidad en la que los usuarios
han llegado a confiar.
● Las pruebas continuas reducen los falsos positivos al priorizar los casos de prueba.
26
5. RESULTADOS
6. CONCLUSIONES
27
más de 5 minutos: si no pasan, es posible que no se inicien otras pruebas. Tal configuración es
la más eficiente para el desarrollo, así como para la entrega, sin embargo, puede requerir
muchos recursos dependiendo del tamaño del proyecto. Si esto es un problema, es posible
planear pruebas, como ejecutar un grupo nocturno de las pruebas de aceptación más comunes.
- Integración continua permite tener un reporte de las pruebas que fallan, es el rol del
ingeniero de calidad de interpretar los resultados
- Es buena práctica para las pruebas continuas ejecutar un control de calidad sobre ellas.
- Es importante ejecutar todo tipo de casos de prueba para asegurar la calidad del
software.
28
7. DICCIONARIO DE TÉRMINOS
6. Entrega continua: implica que todo cambio subido al repositorio y cuyos tests sean exitosos,
pasarán a un servidor donde el conjunto de todos los cambios serán compilados, probados y
verificados.
8. BIBLIOGRAFÍA
Date, Devendra (2016, Noviembre 14). CI/CD automation (Part I). Fecha de consulta: 20-08-13.
Recuperado de https://devopstech.com/learn/blogs/cicd-automation/
Gollamudi, Raja (2015, Mayo 14). Quality Assurance in Continuous Integration. Fecha de
consulta: 20-08-13. Recuperado de https://magenic.com/thinking/quality-assurance-in-
continuous-integration
29
Heck, Joe. (2016, Mayo 26) Six rules for setting up continuous integration systems. Fecha de
consulta: 20-08-25. Recuperado de https://rhonabwy.com/2016/01/31/six-rules-for-setting-up-
continuous-integration-systems/
Kofman, Bar (2017, Deciembre 19). Test Quality in CI/CD – Expert Roundup Fecha de consulta:
20-08-25. Recuperado de https://www.sealights.io/blog/test-quality-in-ci-cd-expert-roundup/
Lee, James (2018, July 5). The Saga of CI/CD and DevOps. Fecha de consulta: 20-09-3.
Recuperado de https://www.level-up.one/saga-ci-cd-devops/
Root, Bryon (2013, Junio 26). Three Golden Rules for Continuous Delivery. Fecha de consulta:
20-08-25. Recuperado de https://www.nwcadence.com/blog/three-golden-rules-for-continuous-
delivery
Selenium Project (2018, Mayo 19). Selenium Documentation. Fecha de consulta: 20-09-1.
Recuperado de https://www.seleniumhq.org/docs/
Toledo, Federico (2017, Julio 28). ¿Qué es un QE o Ingeniero en Calidad?. Fecha de consulta:
20-08-13. Recuperado de https://www.federico-toledo.com/que-es-un-qe-o-ingeniero-en-calidad/
Vishal, Naik (2016, Enero 11). Architecting for Continuous Delivery. Fecha de consulta: 20-08-
16. Recuperado de https://www.thoughtworks.com/insights/blog/architecting-continuous-delivery
Wynne, Matt (2018, Mayo 1). New documentation for Cucumber. Fecha de consulta: 20-09-1.
Recuperado de https://cucumber.io/
30