Universidad Nacional Mayor de San Marcos

Universidad del Perú. Decana de América

Facultad de Ingeniería de Sistemas e Informática
Escuela Profesional de Ingeniería de Software

Implementación de la metodología DevOps para

mejorar el proceso de desarrollo de software del
proyecto Carpeta Fiscal Electrónica en la Fiscalía de la
Nación

TRABAJO DE SUFICIENCIA PROFESIONAL

Para optar el Título Profesional de Ingeniera de Software

AUTOR
Clara Alessandra JUSTINO LÍMACO

ASESOR
Joel Fernando MACHADO VICENTE

Lima, Perú

2021
Reconocimiento - No Comercial - Compartir Igual - Sin restricciones adicionales

[Link]
Usted puede distribuir, remezclar, retocar, y crear a partir del documento original de modo no
comercial, siempre y cuando se dé crédito al autor del documento y se licencien las nuevas
creaciones bajo las mismas condiciones. No se permite aplicar términos legales o medidas
tecnológicas que restrinjan legalmente a otros a hacer cualquier cosa que permita esta licencia.
Referencia bibliográfica

Justino, C. (2021). Implementación de la metodología DevOps para mejorar el

proceso de desarrollo de software del proyecto Carpeta Fiscal Electrónica en la
Fiscalía de la Nación. [Trabajo de suficiencia profesional de pregrado, Universidad
Nacional Mayor de San Marcos, Facultad de Ingeniería de Sistemas de Informática,
Escuela Profesional de Ingeniería de Software]. Repositorio institucional Cybertesis
UNMSM.
 Metadatos complementarios

Datos de autor

Nombres y apellidos CLARA ALESSANDRA JUSTINO LIMACO

Tipo de documento de identidad DNI

Número de documento de identidad 76747416

URL de ORCID [Link]

Datos de asesor

Nombres y apellidos JOEL FERNANDO MACHADO VICENTE

Tipo de documento de identidad DNI

Número de documento de identidad 40476778

URL de ORCID [Link]

Datos del jurado

Presidente del jurado

Nombres y apellidos César Augusto ALCÁNTARA LOAYZA

Tipo de documento DNI

Número de documento de identidad 09132297

Miembro del jurado 1

Nombres y apellidos Augusto Parcemón CORTEZ VÁSQUEZ

Tipo de documento DNI

Número de documento de identidad 08634618

Miembro del jurado 2

Nombres y apellidos JOEL FERNANDO MACHADO VICENTE

Tipo de documento DNI

Número de documento de identidad 40476778

Datos de investigación

Línea de investigación No aplica

Grupo de investigación No aplica

Agencia de financiamiento Propio

País: Perú
Departamento: Lima
Provincia: Lima
Ubicación geográfica de la investigación Distrito: Cercado de Lima
Jr. Carlos Amezaga No. 375
Universidad Nacional Mayor de San Marcos
Latitud: -12.0564232
Longitud: -77.0843327
Año o rango de años en que se realizó la
2021
investigación

2.02.04 -- Ingeniería de sistemas y

comunicaciones
URL de disciplinas OCDE
[Link]
 UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
Escuela Profesional de Ingeniería de Software

Acta Virtual de Sustentación

del Trabajo de Suficiencia Profesional

Siendo las 17:13 horas del día 21 de diciembre del año 2021, se reunieron
virtualmente los docentes designados como Miembros de Jurado del Trabajo de
Suficiencia Profesional, presidido por el Mg. Alcántara Loayza Cesar Augusto
(Presidente), Mg. Cortez Vásquez Augusto Parcemon (Miembro) y el Mg. Machado
Vicente Joel Fernando (Miembro Asesor), usando la plataforma Meet
([Link] para la sustentación virtual del Trabajo de
Suficiencia Profesional intitulado: “IMPLEMENTACIÓN DE LA METODOLOGÍA
DEVOPS PARA MEJORAR EL PROCESO DE DESARROLLO DE SOFTWARE
DEL PROYECTO CARPETA FISCAL ELECTRÓNICA EN LA FISCALÍA DE LA
NACIÓN”, por el Bachiller Justino Límaco Clara Alessandra; para obtener el Título
Profesional de Ingeniera de Software.

Acto seguido de la exposición del Trabajo de Suficiencia Profesional, el Presidente

invitó a la Bachiller a dar las respuestas a las preguntas establecidas por los miembros
del Jurado.

La Bachiller en el curso de sus intervenciones demostró pleno dominio del tema, al

responder con acierto y fluidez a las observaciones y preguntas formuladas por los
señores miembros del Jurado.

Finalmente habiéndose efectuado la calificación correspondiente por los miembros del

Jurado, la Bachiller obtuvo la nota de 18 DIECIOCHO.

A continuación el Presidente de Jurados el Mg. Alcántara Loayza Cesar Augusto,

declara a la Bachiller Ingeniera de Software.

Siendo las 17:55 horas, se levantó la sesión.

_____________________
Presidente
Mg. Alcántara Loayza Cesar Augusto

__________________ _____________________
Miembro Miembro Asesor
Mg. Cortez Vásquez Augusto Parcemon Mg. Machado Vicente Joel Fernando
 AGRADECIMIENTOS

A mi familia por su constante apoyo.

A mi asesor Joel Machado por su compromiso y apoyo brindado para la

elaboración del Trabajo de Suficiencia Profesional.

A la institución que me dio la oportunidad de mejorar mi experiencia profesional

adquiriendo nuevos conocimientos.

IV
 UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
FACULTAD DE INGENIERIA DE SISTEMAS E INFORMÁTICA
ESCUELA PROFESIONAL DE INGENIERÍA DE SOFTWARE

IMPLEMENTACIÓN DE LA METODOLOGÍA DEVOPS PARA MEJORAR EL

PROCESO DE DESARROLLO DE SOFTWARE DEL PROYECTO CARPETA
FISCAL ELECTRÓNICA EN LA FISCALIA DE LA NACIÓN

Autor: Justino Limaco, Clara Alessandra

Asesor: Machado Vicente, Joel Fernando

Título: Trabajo de Suficiencia Profesional para optar por el Título Profesional de

Ingeniero de Software

Fecha: Diciembre 2021

RESUMEN

El presente trabajo de suficiencia profesional para alcanzar el título profesional

de Ingeniero de Software, describe el proyecto de implementación de la
metodología DevOps para el proyecto Carpeta Fiscal Electrónica en la Fiscalía
de la Nación. Para ello, se establece un conjunto de procedimientos y elementos
que aseguran la entrega del software, y se da solución a los inconvenientes
surgidos a lo largo del proceso de desarrollo de software del proyecto Carpeta
Fiscal Electrónica. Haciendo uso de la metodología Scrum se logran los objetivos
planteados en el tiempo estimado mejorando el proceso de integración y
despliegue de software entre un 30% y 40% en los tiempos de entrega del
software y productividad del equipo de desarrollo.

Palabras claves: DevOps, Scrum, Carpeta Fiscal Electrónica, despliegue

continuo, integración continua.

V
 NATIONAL MAJOR UNIVERSITY OF SAN MARCOS
FACULTY OF SYSTEMS ENGINEERING AND INFORMATIC
PROFESSIONAL SCHOOL OF SOFTWARE ENGINEERING

IMPLEMENTATION OF DEVOPS METHODOLOGY TO IMPROVE THE

SOFTWARE DEVELOPMENT PROCESS OF ELECTRONIC PROSECUTOR
FOLDER PROJECT IN THE NATIONAL PROSECUTION

Author: Justino Limaco, Clara Alessandra

Adviser: Machado Vicente, Joel Fernando

Title: Work of Professional Sufficiency to opt for the Professional Title of Software
Engineer

Date: December 2021

ABSTRACT

The present work of professional sufficiency for achieving the professional title of
Software Engineer, describes the project of DevOps methodology
implementation for the Electronic Prosecutor Folder project in the Public
prosecution of the Nation. For this, a set of procedures and elements are
established that ensure the delivery of the software, and a solution is given to the
inconveniences that have arisen throughout the software development process
of the Electronic Fiscal Folder project. Using the Scrum methodology, the
objectives set are achieved in the estimated time, improving the software
integration and deployment process between 30% and 40% in software delivery
times and development team productivity.

Keywords: DevOps, Scrum, Electronic Prosecution Folder, continuous

deployment, continuous integration.

VI
 CONTENIDO
ÍNDICE DE TABLAS .............................................................................................................. VIII
ÍNDICE DE FIGURAS .............................................................................................................. IX
INTRODUCCIÓN ........................................................................................................................ 1
CAPÍTULO I TRAYECTORIA PROFESIONAL .................................................................... 3
1.1. Presentación profesional ....................................................................................... 3
1.2. Experiencia profesional .......................................................................................... 3
1.3. Formación académica ............................................................................................. 6
1.4. Idiomas ........................................................................................................................ 6
CAPÍTULO II CONTEXTO EN EL QUE SE DESARROLLÓ LA EXPERIENCIA ........... 7
2.1. Empresa – actividad que realiza .......................................................................... 7
2.2. Visión ........................................................................................................................... 7
2.3. Misión .......................................................................................................................... 7
2.4. Organización de la empresa .................................................................................. 7
2.5. Área, cargo y funciones desempeñadas............................................................ 9
2.5.1 Área ...................................................................................................................... 9
2.5.2 Cargo .................................................................................................................... 9
2.5.3 Funciones desempeñadas ................................................................................ 9
2.6. Experiencia profesional realizada en la organización .................................. 10
CAPÍTULO III ACTIVIDADES DESARROLLADAS ........................................................... 11
3.1. Situación problemática ......................................................................................... 11
3.1.1 Definición del problema ................................................................................... 11
3.2. Solución .................................................................................................................... 13
3.2.1 Objetivos ............................................................................................................ 13
3.2.2 Alcance Funcional ............................................................................................ 14
3.2.3 Etapas y Metodología ...................................................................................... 14
3.2.4 Fundamentos Utilizados .................................................................................. 16
3.2.5 Implementación de las áreas, procesos, sistemas y buenas prácticas ... 29
3.3. Evaluación ................................................................................................................ 54
CAPÍTULO IV REFLEXIÓN CRITICA DE LA EXPERIENCIA ......................................... 58
CAPÍTULO V CONCLUSIONES Y RECOMENDACIONES ............................................. 59
5.1. Conclusiones........................................................................................................... 59
5.2. Recomendaciones.................................................................................................. 60
BIBLIOGRAFÍA ........................................................................................................................ 61
GLOSARIO ............................................................................................................................... 63
ANEXOS .................................................................................................................................... 65

VII
 ÍNDICE DE TABLAS

Tabla 1: Empresa 1 .................................................................................................................. 3

Tabla 2: Empresa 2 .................................................................................................................. 4
Tabla 3: Empresa 3 .................................................................................................................. 4
Tabla 4: Empresa 4 .................................................................................................................. 4
Tabla 5: Empresa 5 .................................................................................................................. 5
Tabla 6: Formación académica del autor ........................................................................... 6
Tabla 7: Idiomas ....................................................................................................................... 6
Tabla 8 Listado de Sprints ................................................................................................... 15
Tabla 9: Historias de usuario por Sprint .......................................................................... 15
Tabla 10: Lista de componentes ........................................................................................ 33
Tabla 11: Jenkins vs Gitlab CI/CD...................................................................................... 38
Tabla 12: Cantidad de incidencias resueltas por componente .................................. 56
Tabla 13: Detalles de pases a producción ....................................................................... 56

VIII
 ÍNDICE DE FIGURAS

Figura 1: Organigrama Gerencia General .......................................................................... 8

Figura 2: Equipo Proyecto Carpeta Fiscal Electrónica .................................................. 9
Figura 3: Componentes de la CFE ..................................................................................... 12
Figura 4: Herramienta de apoyo ......................................................................................... 16
Figura 5: Transición de desarrollo tradicional a DevOps ............................................ 17
Figura 6: Flujo de funcionamiento Scrum ....................................................................... 26
Figura 7: Almacén de carpeta fiscales en MPFN ........................................................... 29
Figura 8: Procedimiento entrega de software ................................................................ 30
Figura 9: Flujo para entrega de software ......................................................................... 31
Figura 10: Arquitectura DevOps ......................................................................................... 32
Figura 11: Herramienta Gitlab ............................................................................................. 32
Figura 12: Hipervisor para entorno de desarrollo ......................................................... 35
Figura 13: Arquitectura entorno de desarrollo ............................................................... 36
Figura 14: Máquina virtual aplicaciones - desarrollo ................................................... 37
Figura 15: Máquina virtual base de datos - desarrollo ................................................. 37
Figura 16: Gitlab CI/CD ......................................................................................................... 39
Figura 17: Máquina virtual para DevOps.......................................................................... 40
Figura 18: Runners registrados en Gitlab ....................................................................... 40
Figura 19: Configuración de runners ................................................................................ 41
Figura 20: Hipervisor para entorno de preproducción................................................. 42
Figura 21: Arquitectura entorno de preproduccíón ...................................................... 42
Figura 22: Máquina virtual aplicaciones - preproducción ........................................... 43
Figura 23: Máquina virtual base de datos - preproducción ........................................ 44
Figura 24: Máquina virtual para ELK ................................................................................. 45
Figura 25: Nueva arquitectura que integra ELK ............................................................. 46
Figura 26: Home ELK ............................................................................................................ 46
Figura 27: Captura de logs desde ELK ............................................................................. 47
Figura 28: Repositorios Nexus Sonartype....................................................................... 48
Figura 29: Repositorios npm, maven y docker .............................................................. 49
Figura 30: Proyectos en Sonarqube.................................................................................. 49
Figura 31: Quality Gate ......................................................................................................... 50
Figura 32: Colección de scripts en repositorio CFE ..................................................... 51
Figura 33: Tabla flyway generada ...................................................................................... 51
Figura 34: Pipeline Gitlab ..................................................................................................... 52
Figura 35: Ejecución pipeline.............................................................................................. 53
Figura 36: Captura de falla en pipeline ............................................................................. 53
Figura 37: Monitoreo de pipeline ....................................................................................... 53
Figura 38: Historial de ejecución de pipelines ............................................................... 54
Figura 39: Variación de commits en el 2021 ................................................................... 55
Figura 40: Diagrama de líneas de incidencias por mes ............................................... 55
Figura 41: Promedio de días de pase a producción de observaciones .................. 57

IX
 INTRODUCCIÓN

El presente trabajo de suficiencia profesional para alcanzar el título

profesional de Ingeniero de Software describe la implementación de la
metodología DevOps para el proyecto de Carpeta Fiscal Electrónica en la
Fiscalía de la Nación.

En el marco del proceso de modernización del Ministerio Público,

aprobado mediante Resolución de la fiscalía de la Nación N° 650-2017-MP-FN,
y la creación y conformación de la comisión encargada de asegurar el desarrollo
e implementación de la Carpeta fiscal Electrónica (CFE) en el Ministerio Público
aprobada mediante la Resolución de la fiscalía de la Nación N° 572-2017-MP-
FN la Oficina Central de Tecnología de la Información inició el proceso de
automatización del piloto de la Carpeta Fiscal Electrónica del Ministerio Público,
donde se conformó grupos de analistas, desarrolladores, analistas QA y personal
de operaciones para asegurar los objetivos del proyecto.

Durante el desarrollo del proyecto Carpeta Fiscal Electrónica se

logra identificar diferentes necesidades relacionadas a la programación,
integración y despliegue de los artefactos generados, en ese sentido, se realiza
la implementación de la metodología DevOps a fin de mejorar el proceso de
desarrollo de software.

El presente trabajo de suficiencia profesional está estructurado de

la siguiente manera:

En el CAPITULO I se especifican cronológicamente roles y

funciones, actividades, aprendizaje empírico y formal del autor. También se
precisa la experiencia significativa del mismo a través de los proyectos en los
que ha participado durante su experiencia profesional.

En el CAPITULO II se describe al Ministerio Publico, su estructura

orgánica, la visión y la misión, los servicios que brinda y las áreas involucradas
en el proyecto.

1
 En el CAPITULO III se detalla el trabajo realizado respecto a la
implementación DevOps para el proyecto Carpeta Fiscal Electrónica, se expone
el problema, los objetivos, etapas y metodología usada.
En el CAPITULO IV se detalla la reflexión crítica de la experiencia
adquirida a lo largo del proyecto señalando los puntos más relevantes que fueron
clave para el logro de los objetivos.
En el CAPITULO V se describe las conclusiones y
recomendaciones del presente Trabajo Profesional.

2
 CAPÍTULO I
TRAYECTORIA PROFESIONAL

1.1. Presentación profesional

Profesional con grado académico de bachiller en Ingeniería de

Software de la Universidad Nacional Mayor de San Marcos y una Maestría en
Internet de las Cosas en la Universidad Complutense de Madrid. Actualmente se
desempeña como Analista DevOps en el Ministerio Público - Fiscalía de la
Nación.

A lo largo de su experiencia profesional se ha desempeñado en

cargos relacionados al desarrollo y mantenimiento de software con diferentes
lenguajes de programación. Este último año viene desempeñándose en el área
de Arquitectura de Software, donde su último trabajo consiste en la puesta en
marcha de la metodología DevOps para un proyecto.

1.2. Experiencia profesional

Tabla 1: Empresa 1

MPFN - Fiscalía de la Nación

Octubre 2020 - Actualidad
Cargo Analista DevOps
 Instalación y configuración de herramientas de
automatización, integración y despliegue continúo.
 Gestión de creación y despliegue de entornos de desarrollo,
calidad, preproducción y producción.
 Apoyo en el Diseño y Despliegue de los componentes de
generador de notificaciones, Central de Notificaciones y sus
Funciones
mejoras del sistema de información de Notificación Fiscal
Electrónica
 Apoyo en el Diseño y Despliegue de las mejoras de los
componentes de Mesa de Partes Electrónica, Bandeja Fiscal,
Central de Notificaciones y Notificación Fiscal Electrónica y
Casilla Electrónica.
Nota: Elaboración propia

3
Tabla 2: Empresa 2

PLATANITOS
Enero 2019 - Julio 2019
Cargo Programador Backend Senior
 Desarrollo de aplicación para conteo de personas haciendo
uso del reconocimiento facial.
 Desarrollo de servicios para proyecto OMNI, sistema de
Funciones
venta y gestión de almacén omnicanal en la cadena de
tiendas platanitos, en plataforma AWS
 Soporte del sistema de ventas de las tiendas platanitos.
Nota: Elaboración propia

Tabla 3: Empresa 3

MPFN - Fiscalía de la Nación

Febrero 2018 - Diciembre 2018
Cargo Analista Programador
 Resolución de incidencias del Proyecto Piloto Carpeta Fiscal
Electrónica, Generador de Notificaciones, Central de
Notificaciones y Casilla Electrónica.
 Análisis y desarrollo backend-frontend para el componente
de audio y video del Proyecto Piloto Carpeta Fiscal
Electrónica
Funciones  Desarrollo de servicios web para el sistema Generador de
Notificaciones, Central de Notificaciones y Casilla
Electrónica.
 Implementación de Docker y Portainer para la creación y
monitoreo de los entornos de desarrollo, calidad y producción
 Instalación y configuración de Barman para la automatización
del backup de las bases de datos.
Nota: Elaboración propia

Tabla 4: Empresa 4

SUNAT
Febrero 2017 - Enero 2018
Cargo Programador

4
  Resolución de incidencias derivadas de las bases de datos
en la División de Desarrollo de Sistemas Tributarios.
 Resolución de incidencias derivados del módulo de liberación
de fondos en la División de Desarrollo de Sistemas
Tributarios.
 Resolución de incidencias derivados del módulo de
retenciones-percepciones de fondos en la División de
Desarrollo de Sistemas Tributarios.
 Resolución de incidencias derivados del módulo de carrito de
Funciones
pago en la División de Desarrollo de Sistemas Tributarios.
 Mantenimiento y desarrollo de funcionalidades en el módulo
liberación de fondos de la División de Desarrollo de Sistemas
Tributarios.
 Mantenimiento y desarrollo de funcionalidades en el módulo
de retenciones-percepciones de la División de Desarrollo de
Sistemas Tributarios.
 Mantenimiento y desarrollo de archivos batch 4GL de la
División de Desarrollo de Sistemas Tributarios.
Nota: Elaboración propia

Tabla 5: Empresa 5

Ingeniería y RadioFrecuencia SAC

Noviembre 2015 - Enero 2017
Cargo Analista Programador
 Análisis y desarrollo backend-frontend del producto
PhoneStudio: adecuación y desarrollo de funcionalidades
para una estación de radio con el software Asterisk (central
telefónica IP).
Funciones  Análisis y desarrollo backend-frontend de producto para
encendido y apagado remoto de transmisor de onda media
en PC embebida, Raspberry.
 Análisis y desarrollo backend-frontend de una interfaz de
operador para transmisor de onda media: operación,

5
 protección y visualización de parámetros de operación en
PC embebida - Raspberry.
 Implementación de transmisor y receptor de audio streaming
basado en OpenOB en PC embebida - Raspberry.
 Implementación, administración y adecuación de página
web bajo la herramienta Joomla (URL: [Link]).
Nota: Elaboración propia

1.3. Formación académica

Tabla 6: Formación académica del autor

Grado Académico de Bachiller en Ingeniería de Software.

Escuela Académico Profesional de Ingeniería de Software -
2011 - 2016
Facultad de Ingeniería de Sistemas e Informática - Universidad
Nacional Mayor de San Marcos
Grado de Master en Internet de las Cosas
2019 - 2020
Facultad de Informática - Universidad Complutense de Madrid
Curso Java Advance Developer
2018
Cibertec
Taller de Gestión de Procesos
2018
Servir
Curso Java Web Developer
2017
Cibertec
Nota: Elaboración propia

1.4. Idiomas

Tabla 7: Idiomas

Nativo Español
Intermedio Portugués
Avanzado Ingles

Nota: Elaboración propia

6
 CAPÍTULO II
CONTEXTO EN EL QUE SE DESARROLLÓ LA EXPERIENCIA
2.1. Empresa – actividad que realiza

De acuerdo a la definición del Ministerio Público – Fiscalía (2021)

de la Nación se manifiesta lo siguiente:

El Ministerio Público es una entidad soberana del Estado Peruano,

entre sus competencias primordiales se encuentran la defensa de
la legalidad de los derechos ciudadanos y de los intereses públicos;
la representación de la sociedad en juicio, referido a la defensa de
la familia, a los menores e incapaces y el interés social, así como
para custodiar la moral pública; la persecución del delito y
reparación civil.

“También vela por la prevención del delito dentro de las limitaciones

que resultan de la ley y la independencia de los órganos judiciales, la recta
administración de justicia y las demás que le señalan la Constitución Política del
Perú y el ordenamiento jurídico de la Nación.” (MPFN, Cultura Organizacional,
2021)

2.2. Visión

“Somos el Ministerio Público, trabajamos por una justicia

transparente, moderna y efectiva para alcanzar una sociedad pacífica con
inclusión social e igualdad de oportunidades.” (MPFN, Cultura Organizacional,
2021)

2.3. Misión

“Prevenir y perseguir el delito, defender la legalidad, los derechos

ciudadanos y los intereses públicos tutelados por la ley; representar a la
sociedad, al menor y a la familia en juicio; velar por la recta y efectiva
administración de justicia” (MPFN, Cultura Organizacional, 2021)

2.4. Organización de la empresa

La estructura orgánica del Ministerio Público comprende, entre

otras, la Oficina General de Tecnologías de la Información que depende de la

7
Gerencia General y a la que pertenece el equipo del proyecto Carpeta Fiscal
Electrónica.

Figura 1: Organigrama Gerencia General

Nota: Obtenido desde (Estructura Organizacional MPFN, 2021)

El equipo formado para el proyecto CFE está compuesto por

personal contratado por la institución y su estructura organizacional es una
adaptación de la estructura ágil propuesta por Spotify (Radicals, 2021) :

 4 squads o equipos con perfiles multifuncionales que trabajan bajo la

metodología Scrum.
 Coordinador de la tribu: encargado de establecer prioridades,
presupuesto y de asegurar los recursos para el avance de cada squad.
 Coach ágil: encargado de la gestión de avances de cada squad.
 Equipo de infraestructura: encargado de administrar los recursos de
computación, red, almacenamiento y los hardware necesarios para la
operatividad del proyecto de la Carpeta Fiscal Electrónica.

8
 Figura 2: Equipo Proyecto Carpeta Fiscal Electrónica

Nota: Adaptación de (Radicals, 2021)

2.5. Área, cargo y funciones desempeñadas

2.5.1 Área
Las funciones asignadas fueron desarrolladas en el Proyecto
Carpeta Fiscal Electrónica (CFE) de la Oficina General de Tecnologías de la
Información, la que pertenece a la Gerencia General.

2.5.2 Cargo
Analista DevOps, bajo la Jefatura del área de Arquitectura de
Software y coordinación con los squads encargados del desarrollo e
implementación del proyecto Carpeta Fiscal Electrónica.

2.5.3 Funciones desempeñadas

 Definición, diseño y documentación de los modelos implementados de
Integración Continua y Despliegue Automatizado.
 Establecimiento de lineamientos, buenas prácticas y mejora de procesos
relacionados a DevOps.
 Construcción de pipelines de Integración Continua y Despliegue
Automatizado del proyecto.
 Coordinación con los equipos de desarrollo, calidad y producción con el
objetivo de identificar las necesidades de cada frente para la
implementación de DevOps.
 Identificación de oportunidades de mejora en las implementaciones de
DevOps.
9
2.6. Experiencia profesional realizada en la organización

La autora del presente trabajo desempeñó funciones de analista

DevOps para la implementación de Carpeta Fiscal Electrónica, proyecto que a
su vez llevó a cabo la puesta en producción de diferentes componentes que lo
integran. Dentro de ese marco de desarrollo el rol principal de la autora fue la
definición de la metodología de construcción y despliegue de los activos de
software en desarrollo junto al arquitecto de software, dicha tarea se encontraba
condicionada a la capacidad de la Infraestructura Tecnológica ubicada dentro de
las instalaciones, y a los entornos para implementar el desarrollo del proyecto:
desarrollo, calidad y preproducción.

10
 CAPÍTULO III
ACTIVIDADES DESARROLLADAS
3.1. Situación problemática

El 27 de febrero del 2017, en el marco del proceso de

modernización del Ministerio Público aprobado mediante Resolución de la
fiscalía de la Nación N° 650-2017-MP-FN, se dispuso la creación y conformación
de la comisión encargada de asegurar el desarrollo e implementación de la
Carpeta Fiscal Electrónica en el Ministerio Público, la cual fue aprobada
mediante la Resolución de la fiscalía de la Nación N° 572-2017-MP-FN,
adicionalmente, se indica la importancia de incluir en la citada Comisión, a
señores fiscales y funcionarios que en mérito a sus competencias profesionales
y al conocimiento que poseen sobre los procesos que se gestionan en la
institución, complementarán la labor que sus miembros vienen desarrollando.

3.1.1 Definición del problema

El proyecto de Carpeta Fiscal Electrónica tiene por finalidad
optimizar los servicios de acceso de justicia en materia penal, para tal efecto se
busca dotar de servicios y bienes digitales necesarios al Ministerio Público, este
sistema digitaliza los documentos presentados durante la denuncia y la
investigación, permitiendo contar con un registro electrónico de los casos, rápido
acceso a las plataformas de consulta del RENIEC, Policía Nacional, SUNAT,
entre otros, que permitan efectivizar la labor fiscal. La carpeta fiscal electrónica
también permite que los ciudadanos hagan consultas a través de internet, que el
acceso a la información sea de manera transparente y la reducción de los plazos
de los procesos judiciales.

Se identificaron los componentes correspondientes a los procesos

principales del trámite de la Carpeta Fiscal (figura 3), pero aún se tiene que
seguir trabajando en la identificación e implementación de otros procesos, los
cuales, si bien son complementarios al trámite principal, son importantes y
necesarios para tener mapeo de procesos de una manera integral. En mayo del
2019 el Ministerio Publico inicia la implementación de la Carpeta Fiscal
Electrónica, como proyecto piloto en la Fiscalía Especializada en delitos de
Corrupción de Funcionarios de Lima Sur y entre febrero y diciembre del 2020
entran en producción, a nivel nacional, los siguientes componentes:

11
  Generador de Notificaciones: automatiza el proceso de la creación de la
notificación fiscal remitiendo directamente a la Central de Notificaciones.
 Central de Notificaciones: diligencia las notificaciones remitidas hacia los
despachos fiscales
 Mesa de Partes Electrónica (MPE): permite al público presentar los
documentos correspondientes a denuncias hechas.
 Bandeja Fiscal: permite a los despachos fiscales atender las denuncias y
documentos existentes que el público mediante la Mesa de Partes
Electrónica

Figura 3: Componentes de la CFE

Nota: Elaborado por equipo CFE

Con el constante avance y el aumento de los integrantes del

proyecto, surgió la necesidad de organizarlos de tal forma que se tenga eficiencia
en el control del ciclo de vida de software. Dicha eficiencia radica en la corrección
de las siguientes deficiencias que se lograron identificar:

 La infraestructura tecnológica asignada a calidad dispone de solo un

servidor donde los analistas QA realizan pruebas, el despliegue en el
mismo es manual y solo se realiza cuando los desarrolladores han
terminado de realizar un cambio, mejora o nueva funcionalidad.
 La tarea de despliegue es exclusiva del arquitecto de software y el tiempo
que toma está sujeto a su disponibilidad.

12
  Falta de entorno de desarrollo destinado a las pruebas de integración del
equipo de desarrollo frontend y backend.
 Falta de entorno preproducción destinado a las capacitaciones.
 Falta de versionamiento de componentes en producción.
 Dificultad en uso de diferentes versiones de dependencias para cada
componente: frontend y backend.
 Carencia de uso de métricas para evaluación de código desarrollado.
 Las migraciones manuales de las bases de datos empleadas, en
diferentes entornos, se tornaban tediosas.
 Carencia para acceso a logs de componentes ya desplegados.
 Demora de tiempo en los pases a producción.

En base al análisis realizado se concluyó que el problema es

debido a que el proceso de desarrollo de software no presenta estándares ni
buenas prácticas que permitan que el proyecto Carpeta Fiscal Electrónica pueda
automatizar la gestión de los componentes generados.

3.2. Solución

3.2.1 Objetivos
Objetivo general
Implementar la metodología DevOps para mejorar el proceso de
desarrollo de software del proyecto Carpeta Fiscal Electrónica de la Fiscalía de
la Nación.

Objetivos Específicos
 Definir las herramientas que se usa para asegurar la implementación
DevOps
 Definir los pipelines para todos los componentes que se involucran en el
DevOPS
 Realizar la instalación de las herramientas DevOps en los servidores de
la MPFN.
 Realizar la documentación necesaria, comunicar y capacitar a los
miembros de los diferentes equipos, que componen el proyecto Carpeta
Fiscal Electrónica, acerca de las herramientas y como usarse.

13
  Análisis comparativo de los resultados de la implementación de DevOps.

3.2.2 Alcance Funcional

Implementar la metodología DevOps en el equipo de Carpeta Fiscal
Electrónica, para ello se realiza:

 Análisis de la situación actual (modelo de trabajo, herramientas, entre

otros) del equipo de la Carpeta Fiscal Electrónica.
 Establecer metodología de trabajo en los diferentes Equipos de
desarrollo.
 Mejora de procesos y asignación correcta de los roles del equipo de
Carpeta Fiscal Electrónica, incluyendo las prácticas DevOps dentro del
ciclo de vida del Software.
 Implementación de herramientas DevOps destinadas al objetivo del
proyecto.

3.2.3 Etapas y Metodología

Como se mencionó previamente se definió como objetivo la

implementación de la metodología DevOps, se hace uso de las mejores prácticas
mencionadas en el marco de trabajo Scrum para llevar a cabo la gestión del
proyecto, aplicando las etapas y normas que este marco presenta.

1. Se definieron los participantes bajo los roles que Scrum indica:

 Scrum Master: El equipo del proyecto CFE cuenta con 4 squads, en cada
uno de ellos hay un Scrum Master asignado. Para la implementación de
la metodología DevOps se contó con el apoyo temporal de un Scrum
Master.
 Product Owner: Este rol fue asumido por un integrante del equipo de
desarrollo y un integrante del equipo de QA, quienes tuvieron que
realizar la elaboración de las historias de usuario.
 Equipo de Desarrollo: Para este caso está conformada por 2 personas,
el analista DevOps y el arquitecto del proyecto CFE, siendo estas las
personas a cargo de desarrollar el producto.
2. La implementación del proyecto comprendió las siguientes etapas
presentadas en la tabla 8.

14
 Tabla 8 Listado de Sprints
SPRINT PERIODO
Sprint 1 14 de diciembre 2020 – 23 de diciembre 2020
Sprint 2 28 de diciembre 2020 – 9 de enero 2021
Sprint 3 11 de enero 2021 – 22 de enero 2021
Sprint 4 25 de enero 2021 – 5 de febrero 2021
Sprint 5 08 de febrero – 26 de febrero
Sprint 6 1 de marzo 2021 – 12 de marzo 2021
Sprint 7 15 de marzo 2021 – 26 de marzo 2021

Nota: Fuente propia

Se destinó el rango de fechas del 29 de marzo al 30 de abril del 2021 para

la programación de las capacitaciones de cada una las herramientas
instaladas, a cada integrante del equipo CFE.

3. En cada reunión de planeación de los sprints mencionados se definieron los

objetivos, riesgos y la estimación en tiempo de las tareas asignadas para el
equipo de desarrollo Scrum. La tabla 9 es el resultado de las diferentes
reuniones de planeación llevadas a cabo, el detalle de cada historia de
usuario se encuentra en el Anexo 1.

Tabla 9: Historias de usuario por Sprint

SPRINT HISTORIAS DE USUARIO
HU01: Arquitectura DevOps
Sprint 1 HU02: Procedimiento de entrega de software
HU03: Organización de Repositorio Gitlab
Sprint 2 HU06: Implementación de entorno de desarrollo
Sprint 3 HU04: Herramienta Integración Continua / Entrega Continua
Sprint 4 HU7: Implementación de entorno de preproducción
Sprint 5 HU08: Herramienta de Monitorización
HU05: Herramienta para repositorio de artefactos
Sprint 6
HU10: Herramienta para evaluación de código
HU09: Herramienta para migración de BD
Sprint 7
HU011: Pipeline para cada componente

Nota: Elaboración propia

15
4. Como herramienta de apoyo para el seguimiento del proyecto se utilizó
Trello, la cual a través del uso de tarjetas permite gestionar, supervisar y
compartir las tareas de principio a fin.

Figura 4: Herramienta de apoyo

Nota: Captura de la herramienta Trello

3.2.4 Fundamentos Utilizados

[Link] Fundamentos para la implementación

DevOps

Con respecto a la historia de Devops (Willis, 2010) menciona:

Hay diversos sitios que brindan indicios sobre el origen de DevOps,

el más preciso fue en el año 2008 donde se empieza a usar el
vocablo infraestructura ágil en algunos foros de internet, los cuales
buscaban desarrollar las temáticas de desarrollo ágil a nivel de
infraestructura inspirada en una conocida metodología ágil para
desarrollo, y las dos personas que participaban en este diálogo
fueron Patrick Debois y Andrew Shafer quienes generaron un hilo
de internet para dialogar sobre el tema, ya mucho tiempo después
será en un foro europeo agile sysadmin de debate donde se inicia
con dicha temática propiamente.

Asu vez (Lwakatare, y otros, 2019) indican:

DevOps, un acrónimo de desarrollo y operaciones, es un enfoque

en el que los desarrolladores de software y las operaciones
trabajan en estrecha colaboración. El objetivo es mejorar la
comunicación y la integración del desarrollo y las operaciones con

16
 el fin de obtener todos los beneficios de los enfoques de desarrollo
de software moderno que emplean lanzamientos rápidos de nuevas
funciones de software para los usuarios finales y, posteriormente,
aprender de ellos.

Figura 5: Transición de desarrollo tradicional a DevOps

Nota: Obtenido desde (Jaatun, Cruzes, & Luna, 2017)

Cultura DevOps:
En (Consulting, 2021) se indica:
Para lograr un aumento de productos, servicios y la necesidad de
entregar rápidamente actualizaciones de sistemas tecnológicos, la
cultura DevOps juega un papel importante en la metodología ágil y
debe implementarse gradualmente, llevando a la unión entre el
desarrollo de tecnologías de la información y las operaciones, la
automatización de tareas, la transformación de entornos en
entornos escalables, la mejora de los indicadores de eficiencia e
incluso la reducción de costes para las empresas resultan
ventajosas.
También (Walls, 2013) menciona:
En los últimos años se ha debatido mucho sobre lo que es y no es
DevOps. DevOps se trata tanto de cultura como de herramientas,
y la cultura se trata de personas. No se garantiza que dos grupos
de personas creen el mismo tipo de cultura en circunstancias
similares entonces, hablar de un movimiento cultural en términos
absolutos es falso. La implementación de una cadena de
herramientas prescrita no convertirá mágicamente a su equipo en
un equipo de DevOps. El uso de herramientas y flujos de trabajo

17
 compatibles con DevOps puede ayudar al trabajo en equipo de una
manera más DevOps, pero crear una cultura que apoye los ideales
del movimiento DevOps es crucial.

Pilares DevOps:
En (Davis & Daniels, 2016) se identifican cuatro pilares en común
que cualquier equipo u organización que busque implementar DevOps
necesitará dedicar tiempo y recursos:

 Colaboración: Proceso de construcción hacia un resultado

específico a través de interacciones de apoyo y el aporte de
varias personas. Un principio que dio forma al movimiento
DevOps fue la cooperación de los equipos de desarrollo y
operaciones de software.
 Afinidad: Proceso de construir relaciones entre equipos,
navegar por diferentes objetivos o métricas mientras se tienen
en cuenta los objetivos organizacionales compartidos y fomentar
la empatía y el aprendizaje entre diferentes grupos de personas.
 Herramientas: Son un acelerador que impulsan el cambio en
función de la cultura y la dirección actuales. Las opciones de
herramientas pueden percibirse como ganancias fáciles.
 Escalamiento: Es un enfoque en los procesos y pivotes que las
organizaciones deben adoptar a lo largo de sus ciclos de vida.
Más allá de simplemente considerar lo que significa abordar
DevOps, el escalado se puede aplicar en todas las
organizaciones a medida que crecen, maduran e incluso se
reducen.

La combinación de estos cuatro pilares permite abordar los

aspectos culturales y técnicos de la organización. Es importante
que la organización se concentre en uno o dos pilares a la vez
mientras intenta hacer cambios, pero en última instancia, es la
combinación de los cuatro trabajando juntos lo que permitirá un
cambio duradero y efectivo.

18
Elementos:

En (Airaj, 2016) se menciona los siguientes elementos, que deben

formar parte de una metodología DevOps:

 Integración continua: Implica la compilación, prueba y entrega

de la aplicación. Las practicas básicas para este elemento
comprenden: manejar un repositorio de código fuente, compilar
y construir las aplicaciones automáticamente, escribir test
unitarios y correrlos durante la compilación, y construir para
empaquetar la implementación con una periodicidad.
 Entrega continua: Practica diseñada para automatizar el
despliegue de una aplicación en diferentes ambientes
(desarrollo, integración y producción) a lo largo de su ciclo de
vida. Para lograrlo, es necesario contar con una aplicación
debidamente empaquetada y los diferentes entornos deben ser
lo más cercanos posible al de producción. La aplicación debe
implementarse en diferentes entornos sin modificaciones. Por lo
tanto, debe haber archivos de configuración específicos de la
salida para cada entorno que requiera una nueva compilación de
la aplicación.
 Despliegue continuo: Práctica que se lleva a cabo después de
la entrega continua, la principal diferencia con la entrega
continua es que las entregas son desplegadas automáticamente
a producción.
 Infraestructura como código: Capacidad para gestionar
componentes de infraestructura como artefactos programables,
facilitando la manipulación programática de recursos
informáticos y aplicando las mismas prácticas utilizadas en el
desarrollo como pruebas unitarias e integración continua, para
asegurar una mayor estabilidad de las infraestructuras.
 Mejora continua: Automatizar todo es una buena práctica, pero
automatizar y repetir sin cesar los mismos errores
definitivamente no lo es. La cultura DevOps significa mejorar
continuamente sus procesos y herramientas. El primer paso es

19
 recopilar comentarios e indicadores con regularidad. Luego,
sobre la base de esta información, formalice, defina y siga un
plan de mejora.
 Otros procesos: Monitoreo y registro de información relevante
para facilitar el diagnóstico y la resolución de problemas.

Metologías ágiles

En (Kumar & Kumar, 2012) se indica:

Las metodologías ágiles son un grupo de métodos para el

desarrollo de software y se basan en el desarrollo iterativo e
incremental. Las cuatro características principales que son
fundamentales para todas las metodologías ágiles son:
planificación adaptativa, desarrollo iterativo y evolutivo, respuesta
rápida y flexible al cambio y promover la comunicación. Su principal
énfasis está en obedecer los principios de “ligero pero suficiente” y
estar orientado a las personas y centrado en la comunicación.
Como se denomina proceso ligero, es más adecuado para el
desarrollo de pequeños proyectos. El desarrollo de software ágil
considera que los equipos de producción deben comenzar con
aproximaciones simples y predecibles al requisito final y luego
continuar aumentando el detalle de estos requisitos a lo largo de la
vida del desarrollo. Este refinamiento incremental de los requisitos
refina aún más el diseño, la codificación y las pruebas en todas las
etapas de la actividad de producción. De esta manera, el producto
de trabajo de requisitos es tan preciso y útil como el software final
en sí.

En el presente trabajo se detallan las metodologías ágiles Scrum y

la propuesta de Spotify:

Scrum

La definición de Scrum hecha en (Schwaber & Sutherland, 2020) indica:

Scrum es un marco ligero que ayuda a las personas, los equipos y

las organizaciones a generar valor a través de soluciones

20
 adaptables para problemas complejos. Se basa en el empirismo y
el pensamiento lean: donde el empirismo afirma que el
conocimiento proviene de la experiencia y de la toma de decisiones
con base en lo observado y donde el pensamiento Lean reduce el
desperdicio y se enfoca en lo esencial.

Scrum emplea un enfoque iterativo e incremental para optimizar la

previsibilidad y controlar el riesgo, involucra a grupos de personas
que colectivamente tienen todas las habilidades y experiencia para
hacer el trabajo y compartir o adquirir las habilidades según sea
necesario.

Scrum combina cuatro eventos formales para inspección y

adaptación dentro de un evento contenedor, el Sprint. Estos
eventos funcionan porque implementan los pilares empíricos de
Scrum de transparencia, inspección y adaptación.

Roles:

Según lo referido en (Mahnic & Drnovscek, 2005) Scrum

implementa metodología interactiva e incremental a través de los siguientes
roles:

 Product Owner: Responsable de representar los intereses de

todos los interesados en el proyecto y su sistema obtenido.
Mantiene el Product Backlog, la lista priorizada de los requisitos
del proyecto con tiempos estimados para convertirlos en la
funcionalidad completa del producto.
 Team: Responsable de desarrollar la funcionalidad. Los
equipos son autogestionados, auto organizados y
multifuncionales, y son responsables de convertir el Product
Backlog en un incremento de funcionalidad dentro de una
iteración y administrar su propio trabajo para hacerlo. Sus
miembros son colectivamente responsables del éxito de cada
iteración y del proyecto en su conjunto.
 Scrum Master: Responsable de administrar el proceso de
Scrum, como: enseñar Scrum a todos los involucrados en el
21
 proyecto, implementar Scrum para que se ajuste a la cultura de
una organización entregando los beneficios esperados, y
garantizar que todos sigan las reglas y la práctica de Scrum.
Artefactos:

Los elementos producidos como resultado de aplicar el marco

Scrum mencionados en (Mahnic & Drnovscek, 2005) tienen como objetivo el
reducir la cantidad de documentación, y el esfuerzo asociado, al nivel apropiado.
Además, ayudan a optimizar el proceso a través de una constante inspección y
adaptación. Entre ellos tenemos:

 Product Increment: Scrum exige que el equipo de

desarrollo entregue un incremento de producto "hecho" al
final de cada iteración. “Hecho” significa que el producto
podría entregarse al cliente con poco o ningún trabajo
adicional. No es suficiente enviar algo al departamento de
aseguramiento de la calidad para que “ellos puedan
arreglarlo”. La responsabilidad siempre recae en el equipo
de desarrollo. Crear algo potencialmente enviable es
complicado si faltan algunas habilidades en el equipo, por
ejemplo, testers. Esta es una de las razones por las que
Scrum exige equipos multifuncionales con todas las
habilidades necesarias para completar el “Incremento”.
 Product Backlog: contiene la suma de todos los requisitos
del producto que deben ser implementados por el Equipo de
Desarrollo. El propietario del producto es el único
responsable de este retraso. Scrum no prescribe una forma
específica para este artefacto (por ejemplo, Historias de
usuarios) y cada entrada en esta lista se llama simplemente
un "Elemento de la lista de productos pendientes". El
objetivo principal es que el Product Owner cree un
recordatorio para el Equipo de Desarrollo para que no
olviden lo que se requiere que hagan. Por lo general, un
Product Backlog no se configura para que se explique por sí
mismo. En cambio, una colaboración continua entre el

22
 propietario del producto y el equipo de desarrollo asegura
que este artefacto se entienda comúnmente y se
implementen las cosas correctas. Se trata de una desviación
de la gestión de requisitos tradicional en la que las
especificaciones se escriben para ahorrar tiempo de
conversación. El Product Backlog siempre está ordenado
para que en todo momento sea transparente en lo que se
necesita trabajar a continuación.
 Sprint Backlog: consiste en los elementos del Product
Backlog pronosticados por el Equipo de Desarrollo en el
Sprint actual. También contiene el desglose de tareas para
mostrar cómo convertir estos elementos en un Incremento
de producto "hecho". El equipo de desarrollo lo crea durante
la reunión de planificación del Sprint y es el único
responsable. Las personas ajenas al equipo no tienen voz
en su creación o uso. El Sprint Backlog es un artefacto
viviente, refinado, actualizado y corregido todos los días que
muestra el estado exacto del Sprint. Dado que Scrum ve
cada Sprint como un proyecto separado, se puede comparar
con un plan de proyecto. Si no cambia, no es un Sprint
Backlog real.

Eventos:

Todos los eventos descritos en (Maximini, 2015) son obligatorios

en Scrum y forman parte del marco. Su principal objetivo es reducir el tiempo
total de la reunión estructurando el Sprint de una manera que haga que otras
reuniones se vuelvan obsoletas, entre ellos tenemos:

 Sprint: Es una iteración de 30 días calendario o menos.

Al final de cada iteración, se debe entregar un Incremento
de Producto "hecho". No hay tiempo "libre" entre Sprints:
un Sprint sigue al otro sin problemas. Estas iteraciones
marcan el ritmo y el ritmo en Scrum.

23
 Sprint Planning: La reunión de planificación de Sprint es
lo primero que sucede en el ciclo y es el inicio oficial de
un Sprint. Persigue dos objetivos que a menudo están
representados en dos partes de esta reunión, el primer
objetivo es llegar a un acuerdo entre el Product Owner y
el Equipo de Desarrollo sobre lo que se desea en el
próximo Sprint. Esto generalmente termina con un
pronóstico del Equipo de Desarrollo, que le dice al Product
Owner qué esperar al final del Sprint actual. El segundo
objetivo es que el Equipo de Desarrollo planifique este
próximo Sprint, a menudo mediante la creación de tareas
de 8hrs o menos. El resultado final de esta reunión es el
Sprint Backlog que muestra con una granularidad muy
fina lo que el equipo va a abordar y cómo pretenden
lograrlo.
 Daily Scrum: No es una reunión de estado, sino una
reunión de planificación. El equipo de desarrollo planifica
cómo alcanzar el objetivo de Sprint todos los días,
teniendo en cuenta el progreso reciente. Por supuesto, el
Scrum Master puede apoyar al equipo facilitando este
período de tiempo diario de 15 minutos. El estado de
todos se divulga, no por el hecho de conocer el estado,
sino para tomar las decisiones correctas al cambiar el
Sprint Backlog y, por lo tanto, el plan general. El Daily
Scrum también es una gran oportunidad para observar la
motivación y la autoorganización del Equipo de
Desarrollo. No se permiten invitados; generalmente ni
siquiera el Product Owner participa ya que las discusiones
se enfocan a un nivel técnico, que él no comprende.
 Sprint review: La revisión de Sprint está abierta para
cualquiera que esté interesado en el resultado de Sprint.
Su objetivo es colaborar con todos los presentes sobre
qué hacer a continuación, para obtener inspiración e
identificar la necesidad de cambios. Es una reunión de
24
 planificación, dirigida más al plan a largo plazo.
Idealmente, los clientes asistentes prueban el producto
ellos mismos y no solo ven a otra persona hacerlo. Las
presentaciones largas están prohibidas, no se trata de
presentaciones de diapositivas. Además, el objetivo
principal no es aceptar formalmente el resultado del
Sprint. Esto se puede hacer, pero es una muy mala
práctica, ya que generalmente significa que el propietario
del producto sabe, al mismo tiempo que sus partes
interesadas y clientes, qué se hizo y qué tan bien se logró.
 Retrospectiva Sprint: Por lo general, la retrospectiva de
Sprint es el final oficial de un Sprint. Durante esta reunión
se inspecciona el proceso y se identifican las medidas
para mejorarlo. Hay muchas formas de llevar a cabo una
reunión de este. Lo importante es que se definan medidas
concretas; no basta con criticar el statu quo. Solo el
Equipo Scrum está presente en esta reunión, no se
permiten invitados. Es importante realizar la retrospectiva
en cada Sprint y que la lleve a cabo un Scrum Master
experimentado. Esto ayuda a los participantes a
concentrarse y crea un ritmo constante de mejora
continua. Si se lleva a cabo bien, esta reunión puede
revelar grandes oportunidades de mejora de la
productividad que, si se implementan, pueden generar
ganancias tangibles.

La interacción de los diferentes artefactos y eventos de Scrum se

muestran en la siguiente figura:

25
 Figura 6: Flujo de funcionamiento Scrum

Nota: Obtenido desde (Mahnic & Drnovscek, 2005)

El caso Spotify

En el año 2012, la plataforma de streaming Spotify crea su propio

modelo de desarrollo agil y según lo explicado en (Alqudah & Razali, 2016) se
detalla:

El objetivo principal de Spotify es tratar con varios equipos en una

organización de desarrollo de productos. Spotify tiene más de 30
equipos en tres ciudades, pero ha mantenido una mentalidad ágil
en su organización. El enfoque principal de Spotify se puede
describir entonces como poder controlar ágilmente a cientos de
desarrolladores. Spotify tiene numerosos squads, los que son
similares a un equipo Scrum. Cada squad es un equipo
autoorganizado que usa su propio método preferido; algunos de los
squads usan Scrum, los otros usan Kanban y algunos otros usan
la combinación de ambos. Sin embargo, cada escuadrón tiene una
misión a largo plazo y se apega a la misión que es parte del product.
No hay un líder designado en cada squad, pero tiene Product
Owner, responsable de priorizar el trabajo realizado por el equipo.
Sin embargo, la forma en que trabajan los equipos no es un área
que el Product Owner pueda controlar. Los Product Owners de

26
 diferentes squads colaboran para mantener un documento de hoja
de ruta de alto nivel que muestra hacia dónde se dirige Spotify en
su conjunto. Además, el mantenimiento de una cartera de
productos coincidente para cada equipo también es
responsabilidad del Product Owner. Aparte de eso, cada squad
tiene acceso a un entrenador ágil. El ágil entrenador ayudará a la
plantilla a progresar y mejorar su forma de trabajar para conseguir
el objetivo. En Spotify, también hay una tribu. Es una colección de
squads cuyo objetivo es minimizar las dependencias que pueden
obstruir o ralentizar a un squad. Estos squads trabajan en la misma
ubicación de oficina para promover la colaboración entre squads.
Cada tribu está dirigida por un líder de tribu cuya responsabilidad
incluye proporcionar el mejor hábitat posible para los squads dentro
de la tribu. Las tribus están diseñadas básicamente para tener
menos de 100 personas, y realizan reuniones periódicas para
mostrar en qué han trabajado, entregado y logrado para que otros
puedan aprender de ellas.

[Link] Fundamentos para la empresa

Nuevo Código Procesal Penal

“Durante la vigencia del Código de Procedimientos Penales de

1940, el Sistema Judicial Penal se volvió burocrático, rígido y secreto, además
de lento, ineficiente e injusto. Esta situación no permitió garantizar la libertad de
las personas, el desarrollo económico, el bienestar común y la democracia en el
país.” (MPFN, Presentacion Nuevo Codigo Procesal Penal)

Como se indica en (MPFN, Nuevo Codgio Procesal Penal, 2021)

El nuevo modelo procesal penal es el soporte fundamental del

trabajo que desarrollan los fiscales, comprende un conjunto de
normas que aprueban la generación de procesos penales
transparentes y oportunos, en los que los derechos de las partes
procesales están garantizados. También se encuentran bien
definidos: el papel de los jueces, fiscales, policías y abogados para
así ofrecer un proceso penal rápido y justo, cuya investigación

27
 preliminar se realiza conforme con los procedimientos y las
garantías correspondientes, y cuya sentencia revela lo que
realmente se discutió y se logró probar en el juicio oral.

Carpeta Fiscal

En (MPFN, Reglamento de la Carpeta Fiscal, 2006) se manifiesta

la siguiente:

La carpeta fiscal es el instrumento técnico de trabajo que es la base

de la documentación de las actuaciones de la investigación, la
misma está compuesta por:

 La denuncia
 El Informe Policial de ser el caso
 Las diligencias de investigación que se hubieran realizado o
dispuesto ejecutar
 Los documentos obtenidos
 Los dictámenes periciales realizados
 Las actas levantadas
 Las disposiciones emitidas
 Las providencias dictadas
 Los requerimientos formulados
 Las resoluciones emitidas por el Juez de la Investigación
Preparatoria, y toda documentación útil a los fines de la
investigación.

La carpeta original será la que se remita al Juez con los

requerimientos de acusación, sobreseimiento y otras actuaciones
que así lo exijan y en la forma prevista en el Código Procesal Penal.

Los demás documentos e instrumentos de trabajo, como formatos,

resúmenes, notificaciones, oficios, cargos, copias, hipótesis y
estrategias de trabajo relacionadas con la investigación y con el
proceso, entre otros, conforman la carpeta auxiliar, que se
conserva en la Fiscalía para fines del trabajo fiscal y verificación de
los actos procesales realizados.

28
 Figura 7: Almacén de carpeta fiscales en MPFN

Nota: Elaborado por equipo CFE

Carpeta Fiscal Electrónica

En (MPFN, Reglamento de la Carpeta Fiscal, 2006) se indica:

La Carpeta Fiscal Electrónica es aquel elemento que debe tener las

mismas actuaciones y documentos, en el mismo orden que tiene la
carpeta física. Para el uso del registro electrónico se acogen
sistemas de seguridad de datos e información que aseguren su
inalterabilidad e integridad, conforme a los procedimientos
establecidos en el Decreto Legislativo 681, modificado por Ley
26612, y las Directivas de la Fiscalía de la Nación emitidas al
respecto. Una vez que los documentos sean incorporados
digitalmente al medio electrónico y resulten necesarios para su
presentación al Juzgado, se debe transferir los registros que
correspondan al medio físico apropiado.

3.2.5 Implementación de las áreas, procesos, sistemas y buenas prácticas

Según lo indicado en el punto 3.2.3 Etapas y Metodología, en esta

sección se explicará lo desarrollado en cada uno de los 7 sprints que tuvo en el
proyecto.

SPRINT 1
En el presente sprint se completaron tres historias de usuario las
cuales implicaron la organización del repositorio Gitlab, la elaboración de un
procedimiento para la entrega de software y la definición de la arquitectura
DevOps a implementar. Como resultado del release se obtuvo:

29
 Definición del procedimiento de entrega de software:
El procedimiento de entrega para cada componente software (figura 8) se
realiza en los 4 entornos definidos para el proyecto de la Carpeta Fiscal
Electrónica, ellos se definen a continuación:

 Entorno de desarrollo: Ambiente que tiene desplegado los

componentes en desarrollo y se usa para realizar las pruebas de
integridad entre los equipos de frontend y backend.
 Entorno calidad: Ambiente que tiene desplegado los componentes que
el equipo de desarrollo finalizó de corregir o implementar y se usa para
realizar las pruebas de funcionalidad.
 Entorno de preproducción: Ambiente destinado para realizar las
pruebas de aceptación por parte de los usuarios finales(fiscales),
también se usa para realizar las capacitaciones de los componentes ya
desplegados en producción, sus características son una réplica al de
producción.
 Entorno de producción: Ambiente donde se despliegan los
componentes para ser usado por los usuarios finales.

Figura 8: Procedimiento entrega de software

Nota: Elaboración propia

El detalle de los pasos a llevar a cabo para este procedimiento se define en

el siguiente flujo:

30
Figura 9: Flujo para entrega de software

Nota: Elaboración propia

 Definición de la arquitectura DevOps

La arquitectura Devops comprende el conjunto de herramientas a utilizar
y la manera en que se encuentran comunicadas para garantizar el
despliegue y la entrega del producto. La figura 10 muestra la arquitectura
propuesta para la implementación DevOps, la puesta en escena de todos
sus elementos se llevará a cabo en los sprints siguientes.

31
 Figura 10: Arquitectura DevOps

Nota: Elaboración propia

 Organización de repositorio Gitlab

El gestor de repositorios que el equipo hace uso es Gitlab (figura 11), la
cual es una herramienta dedicada al control de versiones y desarrollo de
software colaborativo. Para su uso exclusivo esta herramienta se instaló
en un servidor on premise.

Figura 11: Herramienta Gitlab

Nota: Captura de la herramienta Gitlab

32
En la tabla 10 se muestra todos los componentes y la manera que están
agrupados en el gestor

Tabla 10: Lista de componentes

RUTA
COMPONENTES TECNOLOGIA GRUPO
REPOSITORIO
PORTAL WEB DE MESA
JAVA 8 JEE backend back-mesa-parte
PARTES ELECTRONICAS
FLUJO FISCAL JAVA 8 JEE backend carpeta-fiscal-back
ALMACENAMIENTO cfegestordocument
JAVA 8 JEE backend
NOTIFICACIONES al
ALMACENAMIENTO MESA
JAVA 8 JEE backend repositorio
PARTES
GESTION DE USUARIO JAVA 8 JEE backend cfe-sad

SERVER TOKEN JAVA 8 JEE backend cfe-token

CFETOKEN (MOBILE) KOTILN frontend/mobile app-token

GENERADOR DE cfe-generador-
JAVA 8 JEE backend
NOTIFICACIONES notificaciones
CASILLA ELECTRONICA JAVA 8 JEE backend casilla-backend-v2
investiga-fiscal-
INVESTIGA FISCAL JAVA 8 JEE backend
back
CENTRAL DE
JAVA 8 JEE backend cfe-central-backend
NOTIFICACIONES

NOTIFICE (MOBILE) ANDROID frontend/mobile notifise

CORREO JAVA 8 JEE backend back-correo

RENIEC JAVA 8 JEE backend bk-reniec-rest

SUNAT JAVA 8 JEE backend sunat-bk

INTEGRADOR MESA
back-integrador-
PARTE - CARPETA JAVA 8 JEE backend
mp-cfe
FISCAL
GEO JAVA 8 JEE backend geo

PDF JAVA 8 JEE backend cfe-pdf

JAVA 11
FISTUR backend fistur-back
SPRINT BOOT
MSC-CFE-GESTOR- mcs-cfe-gestor-
JAVA 11
DOCUMENTOS- backend documentos-
SPRINT BOOT
PRODUCER producer
MSC-CFE-GESTOR-
JAVA 11 mcs-cfe-gestor-
DOCUMENTOS- backend
SPRINT BOOT documentos-merge
CONSUMER
SECURITY JAVA 8 JEE backend/libreria mpfn-security

CORE JAVA 8 JEE backend/libreria mpfn-core

mpfn-
ENTITYMANAGER JAVA 8 JEE backend/libreria
entitymanager

33
 CONFIGURATION JAVA 8 JEE backend/libreria mpfn-configuration

CFEEXCEPTION JAVA 8 JEE backend/libreria cfeException

CENTRAL DE cfe-central-
ANGULAR 6 frontend
NOTIFICACIONES FRONT notificaciones-front
GENERADOR DE cfe-generador-
ANGULAR 6 frontend
NOTIFICACIONES notificacion
CARPETA FISCAL cfe-carpeta-fiscal-
VUE JS frontend
ELECTRONICA front
cfe-mesa-parte-
MESA DE PARTES VUE JS frontend
front
MESA DE PARTES denuncias-
VUE JS frontend
ELECTRONICA electronicas
ADMINISTRADOR DE cfe-administrador-
VUE JS frontend
USUARIOS general-vue-front
casilla-electronica-
CASILLA ELECTRONICA VUE JS frontend
frontend
DENUNCIAS denuncias-
VUE JS frontend
ELECTRONICAS electronicas
INVESTIGA FISCAL investiga-fiscal-
VUE JS frontend
FRONT front

Nota: Elaboración Propia

A continuación, se definen los grupos:

 frontend: grupo donde se almacena el código fuente de la interfaz web
desarrollada para cada componente. En adelante cualquier
componente que pertenece a este grupo será referido como
componente frontend.
 frontend/mobile: grupo donde se almacena el código fuente de la
interfaz mobile desarrollada para un componente. En adelante
cualquier componente que pertenece a este grupo será referido como
componente frontend/mobile.
 backend: grupo donde se almacena el código fuente de la lógica
desarrollada para cada componente. En adelante cualquier
componente que pertenece a este grupo será referido como
componente backend.
 backend/libreria: grupo donde se almacena el código fuente de una
funcionalidad que se puede reutilizar en otro componente backend.
En adelante cualquier componente que pertenece a este grupo será
referido como componente backend/libreria.

34
 A su vez se estableció el uso de 3 perfiles para el manejo de dicha
herramienta:
 Maintainer: Perfil de los líderes de squads y encargados de aprobar
los merge request.
 Developer: Perfil para cada integrante del equipo de desarrollo y
analistas QA.
 Administrator: Perfil que maneja el analista DevOps.

SPRINT 2
En el presente sprint se completó una historia de usuario la cual
implicó la implementación del entorno de desarrollo. Como resultado del release
se obtuvo la creación del entorno. Dicho entorno se creó a partir de un hipervisor
(figura 12) con las siguientes características:
 IP: [Link]
 CPU: 8 cores
 RAM: 32 GB
 Almacenamiento: 2 TB

Figura 12: Hipervisor para entorno de desarrollo

Nota: Captura del visualizador VMWARE

35
 La arquitectura para el entorno de desarrollo, presente en la figura
13, se define de la misma manera que está configurado el entorno de calidad:

Figura 13: Arquitectura entorno de desarrollo

Nota: Elaboración propia

Se hizo uso del servicio docker para crear contendedores y

desplegar todos los componentes previamente mencionados, en este caso los
componentes frontend en APACHE y los backend en WILDFLY. En el caso de
los contenedores WILDFLY se repartirán los componentes backend en cada uno
de ellos, tal como se evidencia en la figura 13 el ambiente de desarrollo cuenta
con 2 máquinas virtuales (figura 14 y 15), los detalles se muestran a
continuación:

SERVIDOR DE APLICACIONES
 IP: [Link]
 CPU: 4 cores
 RAM: 15GB
 Almacenamiento: 1,2 TB
 Sistema Operativo: Centos 7

36
Figura 14: Máquina virtual aplicaciones - desarrollo

Nota: Captura del visualizador VMWARE

SERVIDOR DE BASE DE DATOS

 IP: [Link]
 CPU: 4 cores
 RAM: 15GB
 Almacenamiento: 1,2 TB
 Sistema Operativo: Centos 7
 Base de datos: Postgres 7

Figura 15: Máquina virtual base de datos - desarrollo

Nota: Captura del visualizador VMWARE

37
SPRINT 3
En el presente sprint se completó una historia de usuario la cual
implicó la definición de la herramienta de automatización CI/CD. Como resultado
del release se realizó la elección e implementación de la herramienta de
automatización CI/CD.
Para la elección de la herramienta de automatización CI/CD se
tomó en consideración dos herramientas que los miembros del equipo de
desarrollo ya conocían: Jenkins y Gitlab CI/CD. En la tabla 11 se muestra el
cuadro comparativo elaborado para la toma de decisión.

Tabla 11: Jenkins vs Gitlab CI/CD

Característica Jenkins Gitlab CI/CD Cumple

Supervisión del rendimiento NO SI Gitlab CI/CD
Monitoreo del servidor NO SI Gitlab CI/CD
No es necesario
NO, se
instalar nada para
debe hacer
CI / CD incorporado CI / CD, tiene una Gitlab CI/CD
uso de
función
plugins
incorporada
Seguridad en pipeline SI SI Ambas
Programación de ejecución
SI SI Ambas
de pipelines
Gitlab CI/CD, al no
NO, se haría uso
necesitar de otro
Necesidad de otro servidor del servidor donde
SI recurso hadware
para su instalación está instalado
(servidor) para su
Gitlab
uso
Nota: Adaptado de (Singh, Nikita Seth, & Kaur, 2019)

Bajo el cuadro comparativo se tomó la decisión de elegir Gitlab

CI/CD como herramienta de automatización dado que cumple con la mayoría de
funcionalidades requeridas.

Gitlab CI/CD
Herramienta para el desarrollo de software que hace uso de las
siguientes prácticas continuas:
 Integración Continua (CI)
 Entrega Continua (CD)
 Despliegue Continuo (CD)

38
 Figura 16: Gitlab CI/CD

Nota: Elaborado por (Gitlab, 2021)

Proceso de despliegue
Con respecto al proceso de despliegue (Singh, Nikita Seth, & Kaur,
2019) afirman:
Un pipeline se activa cuando se confirma un cambio en un
repositorio Gitlab. Un pipeline para Gitlab es un archivo YML que
contiene una serie de trabajos o etapas a ejecutar. Cada etapa
tiene su propio significado y contiene una lista de pasos a ejecutar
para el despliegue de la última compilación en el servidor. El
pipeline activa un runner para hacer una compilación. Una vez que
se prepara una compilación después de pasar con éxito todos los
casos de prueba declarados, el archivo YML realiza el siguiente
paso de crear una imagen docker a partir de la compilación,
utilizando el archivo Dockerfile almacenado en el repositorio.

El equipo de trabajo ya cuenta con el gestor de repositorios Gitlab, el cual está

instalado en una máquina virtual (figura 17) con las siguientes características:
 IP: [Link]
 CPU: 4 cores
 RAM: 15GB
 Almacenamiento: 1,1 TB

39
Figura 17: Máquina virtual para DevOps

Nota: Captura del visualizador VMWARE

Sobre este servidor se realiza la instalación del componente Gitlab

CI/CD, el cual funciona como servicio y es el encargado de la creación y gestión
de dockers para el trabajo de despliegue. En Gitlab, los runners ejecutan los
trabajos que se definen en el archivo .[Link] de cada repositorio. Un runner
puede ser una máquina virtual, un VPS, una máquina completa, un contenedor
Docker o incluso un grupo de contenedores. Gitlab y el runner se comunican a
través de una API, por lo que el único requisito es que la máquina del runner
tenga acceso de red al servidor de Gitlab. Para el presente proyecto se crearon
2 runners (figura 18), uno destinado para los componentes frontend y otro para
los backend.

Figura 18: Runners registrados en Gitlab

Nota: Captura de la herramienta GitLab

40
 A partir del uso de dockers dichos runners realizan las tareas que
se les asigna en cada componente. Su configuración se muestra en la figura 19:

Figura 19: Configuración de runners

Nota: Elaboración propia

SPRINT 4
En el presente sprint se completó una historia de usuario la cual
implicó la implementación del entorno de preproducción. Como resultado del
release se obtuvo la creación del entorno. Dicho entorno se creó a partir de un
hipervisor (figura 20) con las siguientes características:

 IP: [Link]
 CPU: 8 cores
 RAM: 31.95 GB
 Almacenamiento: 2,6 TB

41
 Figura 20: Hipervisor para entorno de preproducción

Nota: Captura del visualizador VMWARE

La arquitectura para el entorno de preproducción, presente en la

figura 21, comparte las mismas características previamente definidas para el
entorno de desarrollo:

Figura 21: Arquitectura entorno de preproduccíón

Nota: Elaboración propia

42
 Al igual que en el entorno de desarrollo se hizo uso del servicio
docker para crear contendedores donde desplegar todos los componentes
previamente mencionados, en este caso los componentes frontend en APACHE
y los backend en WILDFLY. En el caso de los contenedores Wildfly se repartirán
los componentes backend en cada uno de ellos, tal como se evidencia en la
figura 21. El ambiente de preproducción cuenta con 2 máquinas virtuales (figura
22 y 23), los detalles se muestran a continuación:

SERVIDOR DE APLICACIONES
 IP: [Link]
 CPU: 4 cores
 RAM: 15GB
 Almacenamiento: 1,2 TB
 Sistema Operativo: Centos 7

Figura 22: Máquina virtual aplicaciones - preproducción

Nota: Captura del visualizador VMWARE

SERVIDOR DE BASE DE DATOS

 IP: [Link]
 CPU: 4 cores
 RAM: 15GB
 Almacenamiento: 1,2 TB
 Sistema Operativo: Centos 7

43
Figura 23: Máquina virtual base de datos - preproducción

Nota: Captura del visualizador VMWARE

SPRINT 5
En el presente sprint se completó una historia de usuario la cual
implicó la definición de la herramienta de monitorización. Como resultado del
release se realizó la implementación de la herramienta para el monitoreo de
funcionamiento de las apis para los ambientes de desarrollo, calidad y
preproducción, para dicha actividad se eligió la herramienta ELK.

Para la implementación se asigna una Marquina virtual (figura 24)

con las siguientes características:

 IP: [Link]
 CPU: 4 cores
 RAM: 15GB
 Almacenamiento: 1,2 TB
 Sistema Operativo: Centos 7

44
Figura 24: Máquina virtual para ELK

Nota: Captura del visualizador VMWARE

ELK
La definición se menciona en (elastic, 2021) como:
La unión de 3 proyectos open source: Elasticsearch, Logstash y
Kibana. Elasticsearch es un motor de búsqueda y analítica.
Logstash es un pipeline de gestión de datos del lado del servidor
que consume datos de gran cantidad de fuentes simultáneamente,
los procesa y luego los envía a Elasticsearch. Kibana facilita a los
usuarios la visualización de los datos en gráficos y cuadros
haciendo uso también de Elasticsearch.

Se realiza la instalación y configuración respectiva. De tal manera

se modifican los elementos de la arquitectura previamente descrita para los
entornos de desarrollo, calidad y preproducción. La nueva arquitectura se
muestra en la figura 25.

45
 Figura 25: Nueva arquitectura que integra ELK

Nota: Elaboración propia

Desde un navegador y la ruta que apunta a dicho servidor se podrá

ver los logs capturados de los diferentes contenedores donde fue configurado el
Filebeat (figura 26 y 27), así se garantiza la monitorización el funcionamiento de
los componentes desplegados en los diferentes entornos.

Figura 26: Home ELK

Nota: Captura de la herramienta ELK

46
 Figura 27: Captura de logs desde ELK

Nota: Captura de la herramienta ELK

SPRINT 6
En el presente sprint se completó dos historias de usuario las
cuales implicaron la definición de la herramienta de repositorio de artefactos y
evaluación de código. Como resultado del release para el presente sprint se
realizó la elección e implementación de las herramientas:

 Gestión de librerías y artefactos: Nexus Sonatype

 Evaluación de condigo fuente: Sonarqube

La máquina virtual asignada para estas herramientas es la misma

del sprint anterior donde se encuentra instalada la herramienta ELK. El correcto
funcionamiento de herramientas Nexus y Sonarqube se evidencia durante el
despliegue que se define en el pipeline de cada componente.

Nexus Sonatype

“Nexus es un administrador de repositorios (figura 28). Permite usar

proxy, recopilar y administrar las dependencias de un proyecto, facilitando así la
distribución del software. Internamente, se configura la compilación para publicar
artefactos en Nexus y luego estarán disponibles para otros desarrolladores.”
(OBrien, 2021)

47
Figura 28: Repositorios Nexus Sonartype

Nota: Elaborado por Sonartype

Para los componentes almacenados en Gitlab se configuró 3

grupos de repositorios (figura 29) y su clasificación se basa en las tecnologías
implementadas en el desarrollo:
Componentes Frontend
 npm-private: repositorio de paquetes npm que desarrolla el equipo
 npm-proxy: procesa todo lo que descarga del registro oficial de npm. La
próxima vez que descargue la misma dependencia, se almacenará en
caché en servidor local Nexus.
 npm-group: Agrupa todos los repositorios anteriores y le proporcionará
una única URL para configurar la descarga / despliegue.
Componentes Java EE Backend
 maven-central: repositorio que procesa todo lo que descarga de Maven
Central.
 maven-snapshots: repositorio para el artefacto Maven que implementa
con -SNAPSHOT al final de la etiqueta de versión de su [Link]
 maven-releases: repositorio para el artefacto Maven que implementa sin
-SNAPSHOT al final de la etiqueta de versión de su [Link]
 maven-group: Agrupa todos los repositorios anteriores y le proporcionará
una única URL para configurar la descarga / despliegue.
Almacén de contenedores:
 docker-hub: repositorio que procesa todo lo que descarga del registro
oficial, Docker Hub
 docker-private: repositorio para las imagines Docker que el equipo crea.

48
  docker-group: agrupa todos los repositorios anteriores y proporciona una
única URL para la descarga.

Figura 29: Repositorios npm, maven y docker

Nota: Captura de la herramienta Nexus Sonatype

Sonarqube
En (Lenarduzzi, Lomio, Huttunen, & Taibi, 2020) se indica:
SonarQube es una de las herramientas de análisis de código
estático de código abierto más comunes adoptadas en la industria.
SonarQube calcula varias métricas, como el número de líneas de
código y la complejidad del código, y verifica el cumplimiento del
código con un conjunto específico de "reglas de codificación"
definidas para la mayoría de los lenguajes de desarrollo comunes.
En caso de que el código fuente analizado viole una regla de
codificación o si una métrica está fuera de un umbral predefinido,
SonarQube genera un "problema". SonarQube incluye reglas de
confiabilidad, mantenibilidad y seguridad.

Figura 30: Proyectos en Sonarqube

Nota: Captura de la herramienta Sonarqube

49
 Una vez agregados los componentes del repositorio Gitlab a la
herramienta Sonarqube (figura 30), se definió un gate inicial que solo incluyen
las métricas de bugs, code smells y líneas duplicadas. Dichas métricas, las
cuales se muestran en la figura 31, se usan para realizar la evaluación respectiva
del código en cada despliegue del entorno desarrollo, dichos valores de las
métricas cambiaran sus restricciones según lo indiquen los líderes de cada
squad.

Figura 31: Quality Gate

Nota: Elaborado por Equipo CFE

SPRINT 7
En el presente sprint se completó dos historias de usuario las
cuales implicaron la definición de la herramienta de migración de base de datos
y la integración de los pipelines. Como resultado del release se realizó la
creación de los pipelines en cada componente y también la configuración de la
herramienta para la gestión en las migraciones de BD.

Flyway
“Herramienta para la gestión de los cambios del esquema de base
de datos de nuestra aplicación. Actualiza una base de datos de una versión a la
siguiente mediante migraciones. Las migraciones son en SQL con sintaxis
específica de base de datos o en Java para transformaciones de base de datos
avanzadas.” (Baeldung, 2021)

Para este caso las migraciones se realizaron a través de scripts

almacenados en una carpeta del repositorio del componente (figura 32). Será el
pipeline, definido en cada componente, el encargado de llamar a Flyway para
realizar la respectiva migración. A través del nombre del script y la sintaxis que
este presenta, Flyway reconocerá cada uno de ellos.

50
 Figura 32: Colección de scripts en repositorio CFE

Nota: Elaborado por Equipo CFE

Flyway genera una tabla en cada base de datos que gestiona, en

ella se registra los detalles de cada script que participa en la migración tal y como
se observa en la figura 33.

Figura 33: Tabla flyway generada

Nota: Elaborado por Equipo CFE

Elaboración de pipelines
Al ser Gitlab CI/CD la herramienta encargada de la automatización
de CI/CD se hace uso del archivo “.[Link]”, el cual se define dentro del
repositorio de cada componente. En el pipeline se digita el paso a paso para el
proceso de despliegue en cada entorno y también se indica, de ser necesario, la
conexión con las herramientas que participan en ese despliegue como:
sonarque, flyway, entre otras.

51
 A continuación, en la figura 34 se muestra una pequeña parte del
pipeline correspondiente a un componente backend, en el anexo se coloca su
contenido completo.
Figura 34: Pipeline Gitlab

Nota: Elaboración propia

A partir de la plataforma Gitlab se puede observar el proceso de

despliegue y su resultado. En la figura 35 se evidencia los 3 stages declarados
para el entorno de desarrollo:
1 Evaluación de código realizada por Sonarqube.
2 Migración de base de datos debido a la aparición de nuevos scripts.
3 Despliegue en el contenedor Widlfly, asignado al proyecto.

52
 Figura 35: Ejecución pipeline

Nota: Captura de la herramienta Gitlab

Dicho despliegue se ejecuta automáticamente con cada push que

los desarrolladores hacen a la rama correspondiente a desarrollo y su monitoreo
se muestra en la figura 36. De encontrar algún error en alguna etapa se puede
revisar la consola que Gitlab CI/CD proporciona, tal y como se evidencia en la
figura 37

Figura 36: Captura de falla en pipeline

Nota: Captura de la herramienta Gitlab

Figura 37: Monitoreo de pipeline

Nota: Captura de la herramienta Gitlab

53
 Cada repositorio de los componentes creados presenta
particularidades en sus pipelines y en todos se definen los pasos de despliegue
a llevar a cabo para cada entorno: desarrollo, calidad y preproducción. En el
sprint 1 se identificaron 35 componentes, para cada uno de ellos se creó su
pipeline y su gestión se puede realizar desde la misma plataforma de Gitlab tal
como se muestra en la figura 38.

Figura 38: Historial de ejecución de pipelines

Nota: Captura de la herramienta Gitlab

3.3. Evaluación

La implementación de todos los elementos de la arquitectura

DevOps terminó a finales de abril de 2021, tal como los sprints indican. A
continuación, se presentan algunas gráficas que evidencian las mejoras que
DevOps brindó.

Gitlab tiene la opción para generar algunas métricas a partir de los

datos presentes en cada repositorio, para esta sección se generó la variación de
la cantidad de commits de todo el año 2021. La figura 39 muestra la variación de
la cantidad de commits desde enero hasta el mes de noviembre, y desde finales
de abril se logra ver una tendencia de aumento en la cantidad de commits la cual
se mantiene hasta mediados de mayo, en líneas generales la tasa de commits
mensuales aumentaron en relación a los meses donde no existía DevOps.

54
 Figura 39: Variación de commits en el 2021

INICIO
DevOps

El equipo hace uso del software Mantis para el registro de sus

incidencias, nuevas funcionalidades o mejoras que requieren ser
implementadas, dichos datos se analizaron y se construyeron tablas dinámicas
que generaron los siguientes resultados:

En la figura 40 se evidencia que el total de incidencias resueltas fue

de casi 250, dicha pendiente alcanza su tope a finales de mayo. Sin embargo, la
cantidad de incidencias resueltas a partir de ese mes sigue siendo mayor a las
que hubo antes de marzo.

Figura 40: Diagrama de líneas de incidencias por mes

Incidencia resueltas por mes

300
250
200
150
100 Total
50
0

INICIO
DevOps

El detalle de la cantidad de incidencias resueltas por proyecto se

muestra en la tabla 12, los componentes presentes en la tabla son los que el
equipo de desarrollo trabajó desde enero hasta setiembre.

55
 Tabla 12: Cantidad de incidencias resueltas por componente
Componentes Enero Febrero Marzo Abril Mayo Junio Julio Agosto Setiembre Total
CASILLA ELECTRONICA 15 2 17
ADMINISTRADOR GENERAL 25 6 1 4 4 40
BANDEJA FISCAL 9 2 9 1 2 23
CARPETA FISCAL 77 27 123 52 210 197 176 76 145 1083
FISTUR 34 14 48
GENERADOR NOTIFICACIONES 19 2 4 25
INVESTIGACIÓN_FISCAL 2 39 41
MESA DE PARTES 1 3 1 1 1 9 1 17
Total 136 45 129 68 251 210 210 99 146 1294

INICIO
DevOps

En una columna de la tabla 13 se muestra el cambio en cuanto a

tiempo para el pase a producción por componente, se evidencia que a partir de
mayo el tiempo disminuye progresivamente. También la tabla, en la otra
columna, muestra la cantidad de pases a producción realizados por mes,
evidenciando un aumento significativo desde junio.

Tabla 13: Detalles de pases a producción

Tiempo
promedio de Cantidad de
pase a pases a
producción por producción
componente
Enero 2hrs 2
Febrero 2hrs 30 min 2
Marzo 1hr 30 2
INICIO Abril 1hr 30 3
DevOps Mayo 1hr 2
Junio 1hr 7
Julio 50 min 10
Agosto 45 min 12
Setiembre 45 min 12

Finalmente, la figura 41 muestra un diagrama de barras donde se

obtiene el promedio de días, en cada mes, que toman las nuevas funcionalidades
(features) y las incidencias (defect) en ser manejadas con el equipo de
desarrollo, probadas con el equipo de calidad y ser puestas en producción:

 En el caso de las incidencias, si bien en el mes de mayo la cantidad de días

aumentaron, se evidencia una disminución en los meses posteriores.

56
 En el caso de las nuevas funcionalidades, hasta el mes de mayo la variación
no es muy evidente, pero desde junio hasta setiembre se evidencia la
disminución de esos días promedio.

Figura 41: Promedio de días de pase a producción de observaciones

30
25
20
15
Defect
10
Feature
5
0

INICIO
DevOps

En resumen, las diferentes gráficas y tablas presentadas para la

evaluación de desempeño de la arquitectura DevOps implementada, evidencian
la mejora en el proceso de entrega de software y rendimiento del equipo.

57
 CAPÍTULO IV
REFLEXIÓN CRITICA DE LA EXPERIENCIA

La participación de la autora en todas las etapas del presente

proyecto fue con el rol de Analista DevOps haciendo uso de la metodología
Scrum, la cual significó la participación de diversos miembros del equipo CFE
como desarrolladores y analistas QA.

El éxito de este proyecto está sujeto a la correcta y rápida

adaptación del equipo CFE de la metodología DevOps, y las buenas prácticas
que esta implica. Parte de mi experiencia previa como desarrolladora también
facilitó la comunicación con el equipo de desarrollo para la capacitación de
adaptación DevOps.

Los retos que presentaron una mayor complicación en el proyecto

fueron la implementación de nuevas herramientas que la arquitectura solicitaba,
a pesar que el equipo tenía experiencia y conocimiento sobre algunas, su
instalación y configuración fueron las que generaron mayor consumo de tiempo
en los Sprints.

Finalmente, se considera que el presente trabajo de suficiencia

profesional brindó la oportunidad de mejorar la experiencia profesional como
Analista Devops, la cual recién iniciaba en esta entidad. También se mejoró los
conocimientos y se adquirió experiencia en Scrum ya que anteriormente no se
había trabajado con esta metodología.

58
 CAPÍTULO V
CONCLUSIONES Y RECOMENDACIONES
5.1. Conclusiones

Se logró definir e implementar la metodología DevOps, para el

proyecto de la Carpeta Fiscal Electrónica, a través de las mejores prácticas de
la metodología Scrum en un periodo de 4 meses. La metodología Scrum
benefició el desarrollo del proyecto y se lograron cumplir con los sprints en los
tiempos estimados, donde la implementación fue mejorando con cada entrega
debido a la retroalimentación dada por el Product Owner.

Los entornos de desarrollo, calidad, preproducción y producción ya

cuentan con los pipelines necesarios para garantizar sus entregas continuas de
manera automática. Además, se garantizó la monitorización continua y análisis
del código a través de la métrica propuesta.

La arquitectura DevOps se implementó en los servidores que el

MPFN asigno al equipo CFE y bajo herramientas open source, lo cual permitió
el ahorro en costos en cuanto a licencias.

Se elaboró la documentación correspondiente a las herramientas

implementadas, la capacitación a todo el equipo de la CFE para su uso comenzó
después de la finalización del último sprint y su duración fue de 1 mes.

En relación a los resultados obtenidos, se evidencia que la solución

implementada mejoró el proceso de integración y despliegue de software entre
un 30% y 40% en los tiempos de entrega del software y productividad del equipo
de desarrollo.

59
5.2. Recomendaciones

Si bien se ha logrado la implementación de la metodología DevOps,

existen más herramientas que pueden mejorar la automatización ya lograda
como: pruebas automatizadas, uso de herramientas para simulación de carga o
analizar cuanta más eficiencia se puede lograr con otras herramientas CI/CD.

Se debe ir mejorando las métricas establecidas para la evaluación

estática del código y establecer en el equipo reglas de codificación para definir
un estándar de calidad.

Parte del desarrollo de la cultura DevOps fue la aparición

DevSecOps, la filosofía que promueve la adopción de la automatización de la
seguridad en todo el ciclo de vida del desarrollo de software, su implementación
en el presente proyecto mejoraría la automatización de procesos logrados.

60
 BIBLIOGRAFÍA
Airaj, M. (2016). Enable cloud DevOps approach for industry and higher.
Concurrecy Computat.
Alqudah, M., & Razali, R. (2016). A Review of Scaling Agile Methods in Large
Software Development. International Journal on Advanced Science
Engineering and Information Technology.
Baeldung. (2021). Database Migrations with Flyway. Obtenido de
[Link]
Consulting, G. (2021). DevOps na prática: dia a dia do desenvolvedor. Obtenido
de [Link]
Davis, J., & Daniels, K. (2016). Effective DevOps. O'REILLY.
elastic. (2021). ELK stack. Obtenido de [Link]
stack
Gitlab. (2021). Gitlab Desarrollo continuo. Obtenido de
[Link]
spanish/
Jaatun, M. G., Cruzes, D., & Luna, J. (2017). DevOps for Better Software Security
in the Cloud., (págs. 1-6).
Kumar, G., & Kumar, P. (2012). Impact of Agile Methodology on Software
Development Process. International Journal of Computer Technology and
Electronics Engineering.
Lenarduzzi, V., Lomio, F., Huttunen, H., & Taibi, D. (2020). Are SonarQube Rules
Inducing Bugs? Internation COnference on Software Analysis, Evolution
and Reengineering.
Lwakatare, L., Kilamo, T., Karvonena, T., Sauvolaa, T., Heikkiläc, V., Itkonenc,
J., . . . Lassenius, C. (Junio de 2019). DevOps in practice: A multiple case
study of five companies. Information and Software Technology.
Mahnic, V., & Drnovscek, S. (2005). Agile Software Project Management with
Scrum.
Maximini, D. (2015). The Scrum Culture. Springer.
MPFN. (2006). Reglamento de la Carpeta Fiscal. Obtenido de
[Link]
rpeta_fiscal_aprobado_con_R_748-[Link]
MPFN. (2021). Obtenido de Estructura Organizacional MPFN:
[Link]
[Link]
MPFN. (2021). Cultura Organizacional. Obtenido de
[Link]

61
MPFN. (2021). Nuevo Codgio Procesal Penal. Obtenido de
[Link]
_p.pdf
MPFN. (s.f.). Presentacion Nuevo Codigo Procesal Penal. Obtenido de
[Link]
OBrien, T. (2021). "Why Nexus?" for the Non-Programmer. Obtenido de
[Link]
Radicals, A. (2021). The Spotify Model. Obtenido de [Link]
[Link]/en/the-spotify-model-2-2
Schwaber, K., & Sutherland, J. (2020). Scrum Guide. Obtenido de
[Link]
[Link]
Singh, C., Nikita Seth, G., & Kaur, M. (2019). Comparison of Different CI/CD
Tools Integrated with Cloud Platform. International Conference on Cloud
Computing, Data Science & Engineering (Confluence).
Walls, M. (2013). Building a DevOps Culture.
Willis, J. (Julio de 2010). What Devops Means to Me. Obtenido de
[Link]

62
 GLOSARIO

1. CFE: Acrónimo de Carpeta Fiscal Electrónica

2. MPFN: Acrónimo de Ministerio Público - Fiscalía de la Nación
3. Operaciones: Equipo responsable de mantener no solo la infraestructura de
la propia empresa, como los servidores de archivos, el directorio activo, la
red y las computadoras de los usuarios, sino también los entornos de las
soluciones digitales que ofrece la empresa.
4. Ciclo de vida del software: Estructura que contiene los procesos, actividades
y tareas relacionadas con el desarrollo y mantenimiento de un producto de
software, abarcando la vida completa del sistema, desde la definición de los
requisitos hasta la finalización de su uso
5. Hipervisor: Software que crea y ejecuta máquinas virtuales (VM). A veces
llamado monitor de máquina virtual (VMM), aísla el sistema operativo y los
recursos del hipervisor de las máquinas virtuales y permite la creación y
administración de esas VM.
6. Mantis: Software de código abierto para el seguimiento de errores, se puede
utilizar para rastrear defectos de software para varios proyectos de software
y para mapear su flujo de trabajo de desarrollo de software.
7. Pipeline: Conjunto completo de procesos que se ejecutan cuando activa el
trabajo en sus proyectos. Las canalizaciones abarcan sus flujos de trabajo,
que coordinan sus trabajos, y todo esto se define en el archivo de
configuración del proyecto.
8. VMware: Corporación que proporciona software de virtualización disponible
para ordenadores compatibles X86. Entre este software se incluyen VMware
Workstation, y los gratuitos VMware Server y VMware Player. El software de
VMware puede funcionar en Windows, Linux, y en la plataforma macOS que
corre en procesadores Intel.
9. Barman: Software de código abierto para administración de backups en
bases de datos PostgreSQL.
10. Portainer: Software de código abierto para la gestión remota de
contenedores
11. Filebeat: Software de código abierto para realizar carga y envio de registros
a la herramienta ELK.

63
12. DevSecOps: Enfoque de la cultura, la automatización y el diseño de la
plataforma que integra la seguridad como una responsabilidad compartida a
lo largo de todo el ciclo de vida de TI.
13. CI/CD: Acrónimo de Integración Continua – Despliegue Continuo.
14. Maven: Herramienta que proporciona pautas para realizar configuraciones
mínimas. Compila el código fuente, ejecuta pruebas, empaqueta los
resultados en JAR, WAR, etc. y carga los paquetes en repositorios remotos.

64
 ANEXOS
ANEXO 1: Detalle de historias de usuario

ID HU01

Nombre Arquitectura DevOps

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de infraestructura se precisa contar con una arquitectura
para la implementación DevOps
Criterios de aceptación:
 Definir el tipo de herramientas que participan en la arquitectura DevOps, al
igual que el funcionamiento que tendrá.
 Se debe tomar en cuenta los servidores on premise disponibles.

ID HU02

Nombre Procedimiento de entrega de software

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de desarrollo y calidad preciso de conocer los pasos a
llevar a cabo para realizar la entrega del software desarrollado para:
 Las pruebas de integridad
 Las pruebas en el ambiente de calidad
 Las pruebas de aceptación
 Puesta en producción
Criterios de aceptación:
 Definir cuántos entornos se crearán.
 Definir personal encargado del control de las entregas.
 Documentación respectiva al procedimiento acordado

ID HU03

Nombre Organización de Repositorio GITLAB

Tipo Funcionalidad Técnica

Prioridad Baja

Como miembro del equipo de desarrollo requiero contar con accesos para la
herramienta de control de versiones elegida
Criterios de aceptación:

65
  Definir los roles y crear los usuarios correspondientes en el gestor de
versiones
 Agrupar y crear directorios según contenido de componentes

ID HU04

Nombre Herramienta CI/CD

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de infraestructura preciso definir que herramienta llevará a
cabo las tareas de automatización en la entrega de software
Criterios de aceptación:
 La herramienta debe estar instalada en un servidor on premise y estar lista
para su funcionamiento
 La herramienta debe poder integrarse con el controlador de versiones que el
equipo ahora usa, Gitlab
 La herramienta debe incluir integración para todos los elementos que DevOps
define.
 El uso de la herramienta debe explicarse mediante una capacitación.
 La herramienta debe ser de código abierto.

ID HU05

Nombre Herramienta para repositorio de artefactos

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de desarrollo preciso de una herramienta que sea el
repositorio de las librerías y artefactos que el equipo produzca y requiera.
Criterios de aceptación:
 La herramienta debe estar instalada en un servidor on premise y estar lista
para su funcionamiento.
 La herramienta debe poder integrarse con la herramienta CI/CD.
 La herramienta debe soportar las tecnologías usadas para frontend y backend.
 El uso de la herramienta debe explicarse mediante una capacitación.
 La herramienta debe ser de código abierto.

ID HU06

Nombre Implementación para entorno de desarrollo

Tipo Funcionalidad Técnica

66
Prioridad Alta

Como miembro del equipo de desarrollo preciso de un ambiente para desarrollar las
pruebas de integración entre equipos backend y frontend
Criterios de aceptación:
 El entorno se debe implementar sobre los servidores on premise que el MPFN
brinda
 El entorno debe tener las mismas características técnicas y funcionales como
el entorno de calidad
 El entorno debe integrarse a la herramienta CI/CD instalada

ID HU07

Nombre Implementación para entorno de preproducción

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de calidad preciso de un ambiente para desarrollar

capacitaciones y pruebas de aceptación para el usuario final
Criterios de aceptación:
 El entorno se debe implementar sobre los servidores on premise que el MPFN
brinda
 El entorno debe tener las mismas características técnicas y funcionales como
el entorno de producción
 El entorno debe integrarse a la herramienta CI/CD instalada

ID HU08

Nombre Herramienta de monitorización

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de desarrollo preciso de una herramienta para acceder a
los logs de las aplicaciones desplegadas.
Criterios de aceptación:
 La herramienta debe estar instalada en un servidor on premise y estar lista
para su funcionamiento
 La herramienta debe almacenar los logs de las diferentes componentes
almacenadas en Gitlab.
 La herramienta debe mostrar los logs para los entornos de desarrollo, calidad
y preproducción
 El uso de la herramienta debe explicarse mediante una capacitación.
 La herramienta debe ser de código abierto.

67
ID HU09

Nombre Herramienta para migración de BD

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de desarrollo preciso de una herramienta para automatizar
la ejecución de los scripts DDL y DML.
Criterios de aceptación:
 La herramienta debe estar instalada en un servidor on premise y estar lista
para su funcionamiento
 La herramienta debe integrarse a la herramienta CI/CD instalada
 La herramienta debe contar con un registro de migraciones.
 La herramienta debe soportar la base de datos PostgreSQL.
 La herramienta debe ejecutar las migraciones en los entornos de desarrollo,
calidad y preproducción.
 El uso de la herramienta debe explicarse mediante una capacitación.
 La herramienta debe ser de código abierto.

ID HU10

Nombre Herramienta para evaluación de código

Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de desarrollo preciso de una herramienta para la

evaluación estática de la calidad del código
Criterios de aceptación:
 La herramienta debe estar instalada en un servidor on premise y estar lista
para su funcionamiento.
 La herramienta sólo se usará en el ambiente de desarrollo.
 Las métricas de evaluación, que la herramienta maneja, se deben establecer
a partir de un acuerdo con el equipo de desarrollo.
 El entorno debe integrarse a la herramienta CI/CD instalada.
 La herramienta debe condicionar el despliegue de una aplicación, a través del
cumplimiento de las métricas.
 El uso de la herramienta debe explicarse mediante una capacitación.
 La herramienta debe ser de código abierto.

ID HU11

Nombre Pipelines para componentes

68
Tipo Funcionalidad Técnica

Prioridad Alta

Como miembro del equipo de desarrollo preciso de desplegar y entregar mi aplicación

automáticamente.
Criterios de aceptación:
 Se debe definir un pipeline para cada componente en Gitlab
 El pipeline debe contar con las restricciones que DevOps define.
 La monitorización en la ejecución del pipeline debe estar disponible para todo
aquel que cuente con acceso a Gitlab.
 Los pipelines no pueden exponer en su contenido datos sensibles: passwords

69
ANEXO 2: Archivo pipeline para componente backend Carpeta Fiscal
Electrónica
cache:
paths:
- $CI_PROJECT_DIR/.m2/

variables:
MAVEN_CLI_OPTS: "-s .m2/[Link] --batch-mode"

stages:
- migrationDev
- migrationqa
- migrationPreprod
- sonarqube
- buildDev
- build
- buildPreprod

migrationDev:
only:
refs:
- development
changes:
- src/main/resources/sql/*
stage: migrationDev
image:
name: flyway/flyway:7.7-alpine
entrypoint: [""]
before_script:
- cp -R src/main/resources/sql/* ${HOME}/sql
- echo "[Link]=jdbc:postgresql://${POSTGRES_URL}:5432/${POSTGRES_DB}" >>
${HOME}/[Link]
- echo "[Link]=${POSTGRES_USER}" >> ${HOME}/[Link]
- echo "[Link]=${POSTGRES_PASSWORD}" >> ${HOME}/[Link]
- echo "[Link]=${POSTGRES_SCHEMA}" >> ${HOME}/[Link]
- echo "[Link]=filesystem:${HOME}/sql/" >> ${HOME}/[Link]
- echo "[Link]=__" >> ${HOME}/[Link]
- echo "[Link]=true" >> ${HOME}/[Link]
script:
- flyway repair
- flyway migrate
variables:
POSTGRES_DB: "carpeta_fiscal"
POSTGRES_SCHEMA: "public"
POSTGRES_USER: $postgres_user
POSTGRES_PASSWORD: $postgres_pass
POSTGRES_URL: "[Link]"

migrationqa:
only:
refs:
- qa
changes:
- src/main/resources/sql/*
stage: migrationqa
image:
name: flyway/flyway:7.7-alpine
entrypoint: [""]
before_script:
- cp -R src/main/resources/sql/* ${HOME}/sql
- echo "[Link]=jdbc:postgresql://${POSTGRES_URL}:5432/${POSTGRES_DB}" >>
${HOME}/[Link]
- echo "[Link]=${POSTGRES_USER}" >> ${HOME}/[Link]
- echo "[Link]=${POSTGRES_PASSWORD}" >> ${HOME}/[Link]
- echo "[Link]=${POSTGRES_SCHEMA}" >> ${HOME}/[Link]
- echo "[Link]=filesystem:${HOME}/sql/" >> ${HOME}/[Link]
- echo "[Link]=__" >> ${HOME}/[Link]
- echo "[Link]=.sql" >> ${HOME}/[Link]
- echo "[Link]=true" >> ${HOME}/[Link]
script:
- flyway repair
- flyway migrate
variables:
POSTGRES_DB: "carpeta_fiscal"
POSTGRES_SCHEMA: "public"

70
 POSTGRES_USER: $postgres_user
POSTGRES_PASSWORD: $postgres_pass_qa
POSTGRES_URL: "[Link]"

migrationPreprod:
only:
refs:
- preproduccion
changes:
- src/main/resources/sql/*
stage: migrationPreprod
image:
name: flyway/flyway:7.7-alpine
entrypoint: [""]
before_script:
- cp -R src/main/resources/sql/* ${HOME}/sql
- echo "[Link]=jdbc:postgresql://${POSTGRES_URL}:5432/${POSTGRES_DB}" >>
${HOME}/[Link]
- echo "[Link]=${POSTGRES_USER}" >> ${HOME}/[Link]
- echo "[Link]=${POSTGRES_PASSWORD}" >> ${HOME}/[Link]
- echo "[Link]=${POSTGRES_SCHEMA}" >> ${HOME}/[Link]
- echo "[Link]=filesystem:${HOME}/sql/" >> ${HOME}/[Link]
- echo "[Link]=__" >> ${HOME}/[Link]
- echo "[Link]=.sql" >> ${HOME}/[Link]
- echo "[Link]=true" >> ${HOME}/[Link]
script:
- flyway repair
- flyway migrate
variables:
POSTGRES_DB: "prod_carpeta_fiscal"
POSTGRES_SCHEMA: "public"
POSTGRES_USER: $postgres_user
POSTGRES_PASSWORD: $postgres_pass
POSTGRES_URL: "[Link]"

sonarqube:
only:
- development
stage: sonarqube
image: maven:3.6.3-openjdk-8-slim
script:
- mvn $MAVEN_CLI_OPTS install
- mvn $MAVEN_CLI_OPTS sonar:sonar -[Link]=prueba -
[Link]=[Link] -
[Link]=643f37c280e95075267912c6ee22c4efabdded99 -[Link]=true

buildDev:
only:
- development
stage: buildDev
image: maven:3.6.3-openjdk-8-slim
script:
- mvn $MAVEN_CLI_OPTS install -Pdevelopment wildfly:deploy -
[Link]=[Link] -Dserver=wildfly-server -Dserver-group=mpfn-dev-group-2

build:
only:
- qa
stage: build
image: maven:3.6.3-openjdk-8-slim
script:
- mvn $MAVEN_CLI_OPTS install -Pcalidad wildfly:deploy -[Link]=[Link] -
Dserver=wildfly-server -Dserver-group=mpfn-calidad-group-2
- mvn $MAVEN_CLI_OPTS deploy

buildPreprod:
only:
- preproduccion
stage: build
image: maven:3.6.3-openjdk-8-slim
script:
- mvn $MAVEN_CLI_OPTS install -Ppreprod wildfly:deploy -[Link]=[Link] -
Dserver=wildfly-server -Dserver-group=mpfn-preprod-second
- mvn $MAVEN_CLI_OPTS deploy

71