DEV Community: Juan Manuel Hoyos

CI/CD en AWS: Lab práctico para automatizar el despliegue de sitios web estáticos S3, CloudFront, CodePipeline y CodeBuild

Juan Manuel Hoyos — Fri, 27 Mar 2026 20:41:54 +0000

1. Introducción

Hoy en día, los equipos de desarrollo buscan automatizar el despliegue de aplicaciones para reducir errores manuales y acelerar las entregas. En este laboratorio construiremos un pipeline de CI/CD que desplegará automáticamente un sitio web estático cada vez que se realicen cambios en el repositorio.

Utilizaremos los siguientes servicios de AWS:

Amazon S3: Para alojar nuestro sitio web estático.
AWS CodeBuild: Para construir y empaquetar nuestro sitio web.
AWS CodePipeline: Para orquestar el proceso de CI/CD.
Amazon CloudFront: Para distribuir nuestro sitio web a nivel global.

Al final del laboratorio, cualquier cambio en el repositorio se desplegará automáticamente en el sitio web.

2. Arquitectura de la Solución

La arquitectura del sistema es sencilla pero poderosa. Cada vez que se actualiza el repositorio, se ejecuta automáticamente un pipeline que construye y despliega la aplicación.

Flujo del despliegue:

3. Crear el bucket para el sitio web

Primero debemos crear el bucket que almacenará los archivos del sitio.

Pasos:

Ir a la consola de Amazon S3.
Hacer clic en "Create bucket".
Ingresar un nombre único para el bucket (ejemplo: mi-sitio-web-estatico).
Seleccionar la región deseada.
Configurar las opciones de bucket según tus necesidades.
Hacer clic en "Create bucket".
Desactivar el bloqueo de acceso público para permitir que el sitio sea accesible públicamente.
Configurar el bucket para alojar un sitio web estático:
- Ir a la pestaña "Properties" del bucket.
- Hacer clic en "Static website hosting".
- Seleccionar "Use this bucket to host a website".
- Ingresar index.html como documento de índice.
- Guardar los cambios.
Configurar las políticas de bucket para permitir el acceso público a los archivos del sitio web:
- Ir a la pestaña "Permissions" del bucket.
- Hacer clic en "Bucket Policy".
- Agregar la siguiente política, reemplazando mi-sitio-web-estatico con el nombre de tu bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

4. Crear la distribución CDN

Para mejorar el rendimiento y la distribución global utilizaremos Amazon CloudFront.

Configuración básica:

Origen: El bucket de S3 que acabamos de crear.
Viewer protocol policy: Redirect HTTP to HTTPS
Default root object: index.html (obligatorio para evitar errores 403/404) Una vez creada la distribución, obtendremos un dominio como: https://xxxxx.cloudfront.net que será la URL de nuestro sitio web.

5. Fork del repositorio de ejemplo

Para este laboratorio, utilizaremos un repositorio de ejemplo que contiene el código de nuestro sitio web estático.

Pasos:

Ve a https://github.com/juanhcode/astro-static-site-aws-cicd
Haz clic en el botón "Fork" en la esquina superior derecha.
Selecciona tu cuenta de GitHub como destino del fork.
Clona tu fork en tu máquina local:

git clone https://github.com/tu-usuario/astro-static-site-aws-cicd.git

6. Crear el pipeline

Ahora crearemos el pipeline usando AWS CodePipeline para automatizar el flujo completo de despliegue.

Paso a paso:

Ir a la consola de CodePipeline.
Seleccionar Create pipeline.
Elegir Custom pipeline.
Ingresar el nombre del pipeline (ejemplo: web-static-astro-pipeline).
Dejar la configuración por defecto (rol y artifact store).

Etapa 1: Source

Proveedor: GitHub (a través de GitHub App)
Repositorio: Repositorio: tu fork del repositorio astro-static-site-aws-cicd
Rama: main
Activar detección de cambios (CI automático)

Etapa 2: Build

Proveedor: AWS CodeBuild
Crear un proyecto llamado: website-static-astro
Usar un archivo buildspec.yml en la raíz del repositorio

Etapa 3: Deploy

Proveedor: Amazon S3
Bucket: site-astro-static
Input artifact: BuildArtifact
Activar opción: Extract file before deploy

Esto permite que los archivos del sitio web se publiquen directamente en el bucket.

7. Invalidar cache de CloudFront

Después del despliegue, es necesario limpiar el cache de Amazon CloudFront para que los cambios sean visibles inmediatamente.
Esto puede hacerse agregando un comando en el build:

Mejor práctica: usar variables de entorno
En lugar de hardcodear el ID de la distribución, se recomienda usar variables de entorno en CodeBuild.

Paso 1: Definir variable en CodeBuild

Ir a la consola de CodeBuild.
Editar el proyecto con el nombre que le diste.
En la sección "Environment variables", agregar una variable llamada CLOUDFRONT_ID con el valor del ID de tu distribución de CloudFront.
Asegúrate de seleccionar el runtime adecuado para tu proyecto. Revisa la documentación oficial de runtimes disponibles para elegir la versión que mejor se adapte a tu entorno.

Paso 2: Agregar comando de invalidación en buildspec.yml
Si estás utilizando el repositorio de ejemplo, el buildspec.yml ya tiene la variable definida, pero si no, asegúrate de agregarla en tu buildspec.yml despues de la sección de build:

  post_build:
    commands:
      - echo "Invalidando cache de CloudFront..."
      - aws cloudfront create-invalidation --distribution-id $CLOUDFRONT_ID --paths "/*"

Paso 3: Configurar permisos
Asegúrate de que el rol de servicio de CodeBuild tenga permisos para ejecutar la acción cloudfront:CreateInvalidation. Esto se puede hacer agregando la siguiente política al rol:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloudfront:CreateInvalidation",
      "Resource": "arn:aws:cloudfront::account-id:distribution/distribution-id"
    }
  ]
}

8. Probar el pipeline

Para probar el pipeline, realiza un cambio en el repositorio (por ejemplo, modifica cualquier archivo dentro de src) y haz un commit. Esto debería activar automáticamente el pipeline, que construirá y desplegará el sitio web actualizado. Puedes monitorear el progreso del pipeline en la consola de CodePipeline para asegurarte de que todo se ejecute correctamente. Si el pipeline falla, revisa los logs de CodeBuild para identificar y solucionar cualquier error.

Ejemplo pipeline exitoso:

9. Verificar el despliegue

Una vez que el pipeline se ejecute correctamente, puedes verificar que tu sitio web esté desplegado accediendo a la URL proporcionada por CloudFront:
https://xxxxx.cloudfront.net

10. Resultados finales

Después de configurar el pipeline:

Se realiza un commit en el repositorio
CodePipeline inicia automáticamente
CodeBuild construye el proyecto
Los archivos se despliegan en S3
CloudFront entrega la nueva versión del sitio El sitio queda disponible en: https://xxxxx.cloudfront.net

11. Conclusión

En este laboratorio construimos un pipeline de CI/CD completamente funcional utilizando servicios administrados de AWS. Este enfoque permite automatizar los despliegues, mejorar la consistencia entre entornos y reducir errores humanos.

La combinación de Amazon S3, Amazon CloudFront, AWS CodePipeline y AWS CodeBuild proporciona una solución simple pero poderosa para desplegar sitios web estáticos de forma automática.

🔍 ¿Tu aplicación funciona… pero no sabes qué pasa dentro?

Juan Manuel Hoyos — Mon, 23 Feb 2026 03:06:48 +0000

¿Te ha pasado que tu aplicación responde lento…
pero no sabes exactamente dónde está el problema?

¿El controller responde, pero no sabes cuánto tardó el service?
¿La base de datos está lenta o es tu lógica?
¿Todo funciona en local… pero no entiendes qué ocurre internamente?

Ahí es donde entra la observabilidad moderna.

En este artículo vas a entender, de forma práctica y profunda:

Qué es realmente la observabilidad
Cómo funcionan las trazas distribuidas
Qué hace OpenTelemetry internamente
Para qué sirve el Collector
Cómo Jaeger visualiza todo
Cómo instrumentar automáticamente una aplicación Spring Boot

Todo aplicado a una aplicación tradicional, sencilla, real.

Y lo mejor: puedes ejecutarlo tú mismo en este repositorio:

👉 https://github.com/juanhcode/otel-jaeger-observability-demo

🧠 1. Observabilidad

La observabilidad se basa en tres pilares fundamentales:

Logs → Qué ocurrió
Métricas → Cuánto ocurrió
Trazas → Cómo ocurrió

Las trazas permiten reconstruir el recorrido completo de una solicitud dentro de tu aplicación.

No importa si es una app pequeña.
Si quieres entender su comportamiento interno, necesitas trazas.

🔎 2. ¿Qué es una traza?

Una traza representa el recorrido completo de una petición.

Cliente → Controller → Service → Repository → Base de datos

Cada parte es un Span.

Una traza incluye:

Trace ID
Span ID
Relaciones padre-hijo
Atributos
Eventos
Duración

🏗 3. Arquitectura implementada

Spring Boot
↓
OpenTelemetry Java Agent
↓
OTLP
↓
OpenTelemetry Collector
↓
Jaeger
↓
Jaeger UI

🐳 4. Infraestructura

Se utiliza Docker Compose para levantar:

Jaeger All-in-One
OpenTelemetry Collector

Jaeger UI disponible en:

http://localhost:16686

⚙️ 5. Configuración del Collector

El Collector:

Recibe OTLP
Procesa datos (resource + batch)
Exporta a Jaeger

El processor resource agrega:

service.name
deployment.environment

☕ 6. Aplicación

La aplicación contiene:

Controller REST
Service
Repository JPA
Base H2 en memoria

Endpoints:

POST /user\
GET /user

🎯 7. Instrumentación automática

Variables:

export OTEL_PROTOCOL="grpc"\
export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:4318"\
export OTEL_METRICS_EXPORTER=none

Ejecución:

java -javaagent:opentelemetry-javaagent.jar -jar demo-0.0.1-SNAPSHOT.jar

👀 8. Flujo interno

Se intercepta la petición HTTP
Se crea un span raíz
Se instrumentan Controller, Service y JDBC
Se exporta vía OTLP
El Collector procesa
Jaeger visualiza

🚀 9. Beneficios

Detectar cuellos de botella
Identificar latencias exactas
Entender el flujo real de ejecución
Tener observabilidad estándar
Evitar vendor lock-in

Y todo esto en una aplicación sencilla.

No necesitas tener 20 microservicios para necesitar observabilidad.

🏁 Conclusión

La observabilidad no es solo para arquitecturas complejas.

Incluso una aplicación tradicional puede beneficiarse enormemente de entender qué ocurre internamente.

Con OpenTelemetry y Jaeger puedes pasar de “no sé qué está pasando”
a tener visibilidad completa de tu aplicación en minutos.

Y una vez entiendes lo que ocurre dentro… ya no quieres volver atrás.

Y si quieres probarlo ahora mismo:

👉 https://github.com/juanhcode/otel-jaeger-observability-demo

🚀 Escala tus Pods en Kubernetes usando KEDA

Juan Manuel Hoyos — Mon, 28 Jul 2025 15:25:16 +0000

¿Te has preguntado cómo escalar automáticamente tus aplicaciones en Kubernetes según eventos reales, como una cola con tareas pendientes?

En este artículo te mostraré cómo usar KEDA (Kubernetes-based Event Driven Autoscaler) para escalar dinámicamente un worker en Python en función de los mensajes en una cola Redis.

✅ Ideal si usas colas de trabajo, microservicios, workers o tareas en background.

🧠 ¿Qué es KEDA?

KEDA es un componente liviano que se conecta a tu clúster de Kubernetes y escala tus pods basado en eventos, no solo en métricas de CPU o memoria. Esto permite que escales cuando hay:

Mensajes en una cola
Eventos en Kafka
Entradas en una base de datos
Y muchos otros eventos

📦 Componentes del proyecto

Redis: Almacena tareas en una lista
Worker Python: Procesa tareas de la cola
KEDA: Motor de escalado automático
Kustomize: Gestión de manifiestos Kubernetes

🔧 Requisitos

Cluster Kubernetes (Minikube o en la nube)
kubectl y helm instalados
Docker (opcional, para construir imágenes personalizadas)
KEDA instalado

📂 Archivos del proyecto

Dockerfile (opcional)

FROM python:3.11-slim
WORKDIR /app
RUN pip install redis
COPY worker.py .
CMD ["python", "worker.py"]

worker.py

import redis
import time
import os

redis_host = os.getenv("REDIS_HOST", "localhost")
redis_queue = os.getenv("REDIS_QUEUE", "myqueue")

r = redis.Redis(host=redis_host, port=6379)

print(f"Worker started. Listening on queue: {redis_queue}", flush=True)
while True:
    task = r.blpop(redis_queue, timeout=0)
    if task:
        print(f"Processing task: {task[1].decode('utf-8')}", flush=True)
    time.sleep(1)

keda-scaledobject.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: redis-scaledobject
spec:
  scaleTargetRef:
    name: redis-worker
  pollingInterval: 5
  cooldownPeriod: 30
  minReplicaCount: 0
  maxReplicaCount: 5
  triggers:
  - type: redis
    metadata:
      address: redis.default:6379
      listName: myqueue
      listLength: "5"

redis-worker.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-worker
spec:
  replicas: 0
  selector:
    matchLabels:
      app: redis-worker
  template:
    metadata:
      labels:
        app: redis-worker
    spec:
      containers:
      - name: worker
        image: juanhoyos/redis-worker:latest
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        env:
        - name: REDIS_HOST
          value: "redis"
        - name: REDIS_QUEUE
          value: "myqueue"

redis.yaml

# redis-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        ports:
        - containerPort: 6379
---
apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  ports:
  - port: 6379
  selector:
    app: redis

namespaces.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: keda
  labels:
    name: keda

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - namespaces.yaml
  - redis.yaml
  - redis-worker.yaml
  - keda-scaledobject.yaml

🛠️ Instalación paso a paso

1. Instalar KEDA con Helm

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda \
  --version 2.17.2 \
  --namespace keda \
  --create-namespace

2. Construir imagen personalizada (opcional)

docker build -t <tu-usuario>/redis-worker:latest .
docker push <tu-usuario>/redis-worker:latest

💡 También puedes usar la imagen preconstruida: juanhoyos/redis-worker:latest

3. Desplegar la solución

kubectl apply -k .

🧠 ¿Cómo funciona?

El worker Python se conecta a Redis y monitorea la lista myqueue
KEDA mide la longitud de la cola
Si hay más de 5 mensajes, escala hasta 5 pods
Cuando la cola está vacía, reduce a 0 pods

🧪 Probar el autoscaling

1. Acceder al pod de Redis

kubectl exec -it deploy/redis -- sh

2. Generar tareas de prueba

i=1; while true; do
  echo "Enviando tareas del $i al $((i+39))"
  for j in $(seq $i $((i+39))); do
    redis-cli -h redis rpush myqueue "task$j"
  done
  i=$((i+40))
  sleep 10
done

3. Monitorear los pods

kubectl get pods -w

🏁 Conclusión

KEDA permite construir sistemas eficientes que escalan según la demanda real. Es perfecto para:

Workers en background
Sistemas basados en colas
Procesamiento de datos
Automatización de tareas

¿Interesado en ver ejemplos con Kafka o RabbitMQ? ¡Déjalo en los comentarios! 🚀

📚 Recursos adicionales

How I Got SonarCloud to Detect Test Coverage in a Spring Boot Project with JaCoCo

Juan Manuel Hoyos — Mon, 05 May 2025 16:53:02 +0000

Recently, I ran into a pretty common problem while working on a Spring Boot project with SonarCloud: test coverage wasn't being reported correctly. Even though my tests were running fine, SonarCloud was showing 0% coverage. 🤯

After digging through the docs and trying different configurations, I finally got everything working. Here's exactly what I did, in case it helps you too.

1. Add `mockito-inline` dependency

One issue I had with Mockito was mocking final classes or static methods. To solve this, I added the following dependency to my pom.xml:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-inline</artifactId>
    <version>5.2.0</version>
    <scope>test</scope>
</dependency>

2. Configure JaCoCo properly

The JaCoCo plugin needs to be configured correctly to generate the jacoco.xml file, which is what SonarCloud uses to calculate code coverage. Here’s the configuration I used in pom.xml:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.8</version>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
            <configuration>
                <destFile>${project.build.directory}/jacoco.exec</destFile>
                <propertyName>surefireArgLine</propertyName>
            </configuration>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
            <configuration>
                <formats>
                    <format>XML</format>
                </formats>
            </configuration>
        </execution>
    </executions>
</plugin>

You’ll also need to configure the Surefire plugin to pass the argLine property:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <argLine>@{surefireArgLine} -Xshare:off</argLine>
    </configuration>
</plugin>

3. Configure SonarCloud

To let SonarCloud find the generated report, you need to specify the path to jacoco.xml. Add this to your configuration:

sonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml

You can do this either in:

A sonar-project.properties file, or
Directly in the SonarCloud web UI:

Go to your project in SonarCloud.
Navigate to Administration > General Settings > JaCoCo.
In the "Path to XML report" field, set:

   target/site/jacoco/jacoco.xml

✅ The Result

After applying all these settings, I ran:

mvn clean verify

The coverage report was generated correctly, and SonarCloud finally recognized the actual test coverage. 🎉

📝 Final Thoughts

Connecting JaCoCo and SonarCloud in a Spring Boot project isn’t always straightforward, especially if you're just getting started. Hopefully, this guide saves you some debugging time.

Did you run into a similar issue or find another solution? Let me know in the comments! 👇

Cobertura de pruebas en Spring Boot con Jacoco y SonarCloud: configuración paso a paso

Juan Manuel Hoyos — Mon, 05 May 2025 16:04:19 +0000

Hace poco me encontré con un problema bastante común al trabajar con proyectos en Spring Boot y SonarCloud: la cobertura de pruebas no se estaba reportando correctamente. Aunque las pruebas se ejecutaban sin errores, en SonarCloud la cobertura aparecía como si fuera 0%. 🤯

Después de investigar y probar diferentes configuraciones, logré que todo funcionara. Aquí te comparto lo que hice, por si te sirve.

1. Agregar la dependencia de `mockito-inline`

Uno de los problemas que tuve al usar Mockito fue con clases finales o métodos estáticos. Para solucionarlo, agregué esta dependencia en el archivo pom.xml:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-inline</artifactId>
    <version>5.2.0</version>
    <scope>test</scope>
</dependency>

2. Configurar Jacoco correctamente

El plugin de Jacoco debe estar bien configurado para generar el archivo jacoco.xml, que es el que SonarCloud usa para calcular la cobertura. Esta fue la configuración que usé en el pom.xml:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.8</version>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
            <configuration>
                <destFile>${project.build.directory}/jacoco.exec</destFile>
                <propertyName>surefireArgLine</propertyName>
            </configuration>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
            <configuration>
                <formats>
                    <format>XML</format>
                </formats>
            </configuration>
        </execution>
    </executions>
</plugin>

También fue necesario configurar el plugin de Surefire para que reciba los argumentos necesarios:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <argLine>@{surefireArgLine} -Xshare:off</argLine>
    </configuration>
</plugin>

3. Configurar SonarCloud

Para que SonarCloud encuentre el archivo generado por Jacoco, es necesario agregar la siguiente ruta en su configuración:

sonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml

Puedes hacer esto de dos formas:

En el archivo sonar-project.properties (si lo estás usando).
O directamente en la configuración del proyecto en la web de SonarCloud:

Ve a tu proyecto en SonarCloud.
Abre Administration > General Settings > JaCoCo.
En el campo "Path to XML report", coloca:

   target/site/jacoco/jacoco.xml

✅ Resultado

Después de aplicar estas configuraciones y ejecutar:

mvn clean verify

El reporte de cobertura fue generado correctamente y SonarCloud empezó a reconocer la cobertura real de las pruebas. 🎉

📝 Conclusión

No siempre es obvio cómo conectar bien Jacoco con SonarCloud en un proyecto Spring Boot, especialmente si estás empezando. Espero que este post te haya ayudado a evitar horas de prueba y error.

DEV Community: Juan Manuel Hoyos

CI/CD en AWS: Lab práctico para automatizar el despliegue de sitios web estáticos S3, CloudFront, CodePipeline y CodeBuild

1. Introducción

2. Arquitectura de la Solución

3. Crear el bucket para el sitio web

4. Crear la distribución CDN

5. Fork del repositorio de ejemplo

6. Crear el pipeline

7. Invalidar cache de CloudFront

8. Probar el pipeline

9. Verificar el despliegue

10. Resultados finales

11. Conclusión

🔍 ¿Tu aplicación funciona… pero no sabes qué pasa dentro?

🧠 1. Observabilidad

🔎 2. ¿Qué es una traza?

🏗 3. Arquitectura implementada

🐳 4. Infraestructura

⚙️ 5. Configuración del Collector

☕ 6. Aplicación

🎯 7. Instrumentación automática

👀 8. Flujo interno

🚀 9. Beneficios

🏁 Conclusión

🚀 Escala tus Pods en Kubernetes usando KEDA

🧠 ¿Qué es KEDA?

📦 Componentes del proyecto

🔧 Requisitos

📂 Archivos del proyecto

Dockerfile (opcional)

worker.py

keda-scaledobject.yaml

redis-worker.yaml

redis.yaml

namespaces.yaml

kustomization.yaml

🛠️ Instalación paso a paso

1. Instalar KEDA con Helm

2. Construir imagen personalizada (opcional)

3. Desplegar la solución

🧠 ¿Cómo funciona?

🧪 Probar el autoscaling

1. Acceder al pod de Redis

2. Generar tareas de prueba

3. Monitorear los pods

🏁 Conclusión

📚 Recursos adicionales

How I Got SonarCloud to Detect Test Coverage in a Spring Boot Project with JaCoCo

1. Add mockito-inline dependency

2. Configure JaCoCo properly

3. Configure SonarCloud

✅ The Result

📝 Final Thoughts

Cobertura de pruebas en Spring Boot con Jacoco y SonarCloud: configuración paso a paso

1. Agregar la dependencia de mockito-inline

2. Configurar Jacoco correctamente

3. Configurar SonarCloud

✅ Resultado

📝 Conclusión

1. Add `mockito-inline` dependency

1. Agregar la dependencia de `mockito-inline`