But there’s another problem I run into constantly: someone recommends a series, or I stumble across something interesting in an article, a trailer, or an ad — and the first question is always “where do I actually watch this?” I Google it, and every result assumes I’m in the US. Netflix US, Hulu, HBO Max, Peacock — none of which help me if I’m in Europe. The thing is, streaming catalogues aren’t global. A series that’s on Netflix in the US might be on HBO in Spain, on Amazon in Germany, or simply unavailable where you are until a completely different date. Sometimes it’s not even on streaming — it’s on a cable channel or a regional service you’d never think to check.

I wanted a single place — my place — to solve both problems: know what I’m watching and where I left off, and instantly see where something is available in my country, on my services. So I built one.

This is StreamTrack: a full-stack mobile app built with Flutter, FastAPI, Supabase, and Google Cloud Run, currently in its first beta test.

⚠️ This project is actively under development. Everything described here represents the current state of the first beta. Features, architecture, and decisions are evolving. This article will be updated as the app grows.

What StreamTrack Does

StreamTrack lets you:

• Search series and movies (powered by TMDB + OMDB)
• Track your progress per season and episode
• Know what’s next — always see the next episode you haven’t watched
• See where to watch — streaming availability by country (Netflix, HBO, Disney+…)
• Configure your platforms — the app highlights what’s available on your services
• Get daily updates — new episodes, season premieres, status changes for everything in your list
• Rate series and individual episodes (1–5 stars)
• Share — send a series card (name, ratings, synopsis, where to watch) to anyone

Why Build It Instead of Using an Existing App?

Mainly because I wanted to. But also:

• Existing trackers are either too social (Letterboxd, Trakt) or too bloated
• Streaming availability data is rarely accurate or region-aware
• I wanted to experiment with a full-stack mobile architecture end-to-end — from API design to mobile deployment
• It’s a great playground for decisions I make daily at work (auth, cloud hosting, data modeling) but applied to something personal

Tech Stack

Architecture

The architecture follows a clean separation between the mobile client and the backend API. The app never talks to TMDB or Supabase directly from the device — everything goes through the FastAPI backend. This keeps API keys off the device and centralizes cache and business logic.

┌──────────┐     ┌──────────────┐     ┌─────────────────┐     ┌──────────┐
│  Flutter │────▶│ Supabase     │     │ Google Cloud Run│────▶│ TMDB     │
│  App     │     │  Auth (JWT)  │     │ (FastAPI)       │────▶│ OMDB     │
│  iOS/and │     └──────────────┘     │  $0 free tier   │     └──────────┘
│          │──── Bearer token ──────▶│                 │
│          │◀──── JSON data ─────────│                 │
│ SQLite   │                          └────────┬────────┘
│ (cache)  │                                   │
└──────────┘                          ┌────────┴──────────┐
                                       │ Supabase PostgreSQL│
                                       │ (user data, lists) │
                                       └───────────────────┘

Why a backend instead of going BaaS-direct?

It’s tempting to have the Flutter app talk directly to Supabase. It’s simpler to set up. But it means putting your TMDB/OMDB API keys inside the app bundle — where anyone can extract them. Beyond security, a backend also means:

• Shared cache — one TTL-based in-memory cache for all users instead of each device hammering TMDB independently
• Updatable logic — fix a bug or add a feature without pushing a new app version
• Controlled rate limiting — OMDB allows 1,000 req/day free; with a backend that’s easily manageable

Key Decisions

Supabase over Firebase

Firebase was the obvious first choice. But once I looked at the data model — series, seasons, episodes, watched episodes, user ratings, per-user platform config — it’s fundamentally relational. Firestore’s document model fights you at every join.

Supabase gives me PostgreSQL (real SQL, real foreign keys, real joins) with auth and a decent free tier. Same 50K MAU gratis. Same Google OAuth and Apple Sign In support. And the auth integrates with the database via Row Level Security. It was the right fit.

Cloud Run over Railway/Render

A 30-second cold start on Render Free is a deal-breaker for a mobile API. Cloud Run scales to zero (costs nothing when idle) and wakes in ~2 seconds. The free tier covers the entire beta phase comfortably.

Flutter over React Native

I had prior experience with Flet (Python’s Flutter wrapper), so the widget model wasn’t completely new. Flutter’s dark theme support is first-class, the animation primitives are clean, and the hot reload cycle is fast. A single codebase runs natively on both iOS and Android with no compromise on performance.

Backend Design

The FastAPI backend exposes a clean REST API with Swagger UI at /docs. A few design choices worth noting:

TTL Cache in memory — TMDB search results are cached for 15 minutes, series detail for 1 hour, streaming availability for 6 hours. This keeps API calls minimal without needing Redis or any external cache layer.

Multi-language and multi-country — every endpoint accepts lang and country params. The same API serves a user in Spain (Netflix ES catalogue) and a user in Germany (Netflix DE catalogue) without any code changes.

Upcoming episodes — /api/me/upcoming tells you exactly what episode you should watch next in every series you’re currently following. It’s the feature I use most.

GET  /api/me/upcoming              → Next episodes for "watching" series
GET  /api/me/whats-new             → New episodes / season premieres in my list
GET  /api/trending/my-platforms    → Trending filtered by the user's services
GET  /api/series/{id}/similar      → "You might also like" recommendations

The Flutter App

The app has three main tabs: Home, Search, and My List. A Settings screen lets you configure your preferred streaming platforms — once set, the app highlights available content everywhere.

Home

Four sections load on startup: What’s New (updates from your list), Up Next (your immediate watchlist), On Your Platforms (trending content on your services), and Trending (global top 20 for the week). All sections use shimmer skeletons while loading — no blank screens.

Search

A single search box returns series and movies in separate sections. Results badge in green if the title is available on one of your configured platforms — the check happens lazily in background, so the UI isn’t blocked.

Series Detail

The detail screen shows poster, all three ratings (TMDB / IMDB / Rotten Tomatoes), synopsis, streaming availability chips with platform logos, a “You might also like” horizontal scroll, and the full season and episode breakdown. Episodes are interactive — tap to expand synopsis, checkbox to mark as watched. The status banner at the top shows your current progress and lets you change platform or status in one tap.

My List

Filter chips let you switch between All, Watching, Completed, and On Hold. Cards show poster, platform, progress (S02E04), and the name of the next episode. Swipe to delete with an undo snackbar. Pull to refresh. Within Watching, series with pending episodes float to the top.

Settings

The settings screen loads all available streaming platforms for your country dynamically from the API, complete with logos. Toggle your services on or off — changes save automatically. Selected platforms move to the top. From that moment, the entire app adapts: Home filters trending content to your services, Search badges matching results, and Detail highlights where you can actually watch something.

Light / Dark Mode

The app ships with full light and dark theme support. The toggle lives in the AppBar — state persists across sessions. All status colors (watching, completed, on hold, planned) adapt correctly to both themes.

Distribution: First Beta

Android testers receive APKs via a build script that packages the release build and distributes it directly — no Play Store required for beta. iOS installation is currently manual (cable + Xcode), with TestFlight planned before the public launch.

The backend runs on Cloud Run (Madrid region, europe-southwest1) and the database is live on Supabase PostgreSQL. Beta users authenticate with email and password via Supabase Auth. Google Sign In and Apple Sign In are next on the roadmap before the public store submission.

What’s Next

The freemium model is straightforward: core tracking features are free with ads, and a premium subscription removes ads and unlocks advanced features — to be defined as beta feedback comes in.

Closing Thoughts

StreamTrack started as a personal itch to scratch and turned into a full production-grade architecture: mobile + API + auth + cloud hosting, all for $0/month at beta scale.

The most interesting part wasn’t the features — it was the sequence of decisions: why a backend over BaaS-direct, why Supabase over Firebase, why Cloud Run over Render. Each one had a concrete technical reason, not just preference.

The beta is running. If you’re interested in trying it or following the progress, reach out — I’d love the feedback.

Last updated: June 2026

Introduction

A well-designed automation pipeline is far more than just CI/CD — it’s the backbone of modern infrastructure delivery.

From an automation perspective, it is fascinating how we can integrate a wide range of tools, technologies, languages, and processes into a unified workflow capable of achieving complex goals. The ability to chain identity federation, infrastructure provisioning, scripting, and multi-repository orchestration into a single coherent flow is what separates a pipeline from a platform.

Modern delivery systems are increasingly expected to orchestrate full lifecycle operations: executing tests, provisioning storage, creating environments, and coordinating deployments across multiple repositories. In mature setups, the pipeline is no longer just a build runner — it becomes a distributed control layer that governs how infrastructure is created, configured, and maintained.

This shift is precisely what motivated the work described here.

Project Context

In a recent initiative, I designed and implemented an automation framework centered on GitLab CI that integrates:

• Workload Identity Federation (OIDC) — for secretless, token-based cloud authentication
• Terraform — as the Infrastructure as Code backbone
• Reusable multi-repository pipeline components — shared CI/CD logic across projects
• Custom automation scripts (Bash, Python, or any preferred language) — for programmable orchestration logic

The primary objective was to enable secure, scalable, and reusable infrastructure orchestration, moving away from isolated pipeline jobs toward a platform-oriented approach.

⚠️ Note: This project is actively under development. The architecture described here represents the current state, but we are continuously iterating — adding new automation jobs, improving existing ones, and expanding coverage. This article will be updated as the platform evolves.

Architecture Overview

The following diagram represents the conceptual architecture and flow of the system:

At a high level, the system operates as follows:

1. A developer pushes code to a GitLab repository
2. The GitLab CI pipeline acts as the central Automation Hub
3. The pipeline requests an OIDC token from GitLab
4. Workload Identity Federation exchanges the token for temporary cloud credentials — no static secrets involved
5. Terraform provisions or updates infrastructure across target environments (Dev, Test, Staging, Prod)
6. Custom Bash & Python scripts orchestrate additional logic, validations, and workflows
7. The pipeline triggers downstream pipelines across multiple repositories via cross-repo triggers
8. Target environments are bootstrapped automatically with all required resources
9. Monitoring & Feedback loops provide visibility through logs, alerts, and notifications

This model enables strong security guarantees while maintaining a high degree of automation and flexibility.

Key Design Principles

🔐 Secretless Authentication

By leveraging OIDC and Workload Identity Federation, the pipeline avoids static credentials entirely. Trust is dynamically established at runtime based on the pipeline’s identity.

How it works:

• GitLab issues a short-lived OIDC token for each pipeline execution
• The cloud provider validates the token against a pre-configured trust policy
• Temporary credentials are issued with scoped permissions
• Credentials expire automatically — no rotation needed

Impact:

• Eliminated credential leakage risk
• Simplified credential lifecycle management
• Improved auditability and traceability
• Compliance-friendly by design

♻️ Reusable Pipeline Components

Instead of duplicating CI/CD logic across repositories, pipelines are designed as reusable building blocks hosted in a central repository. Any project — regardless of team or domain — can adopt the full automation pipeline with a single include directive pointing to the central repo.

How it works:

• The complete pipeline logic lives in a dedicated central repository
• Any remote project can consume it by adding a simple include: remote in their .gitlab-ci.yml
• In many cases, only minimal YAML configuration is needed — a few variables to define the project’s context
• The complexity is fully abstracted: the user doesn’t need to understand the underlying orchestration
• Updates to the central pipeline propagate automatically to all consumers

Example — what the user sees:

include:
  - project: 'platform/automation-pipeline'
    ref: main
    file: '/templates/full-pipeline.yml'

variables:
  ENV: "dev"
  PROJECT_NAME: "my-service"

That’s it. The entire automation framework — OIDC auth, Terraform provisioning, environment bootstrapping — is available with just a few lines.

Benefits:

• Dead simple adoption — teams don’t build pipelines, they just include one
• Standardization across teams and projects
• Dramatically reduced duplication and maintenance burden
• Faster onboarding — new projects get full pipeline capabilities instantly
• Consistent security and quality practices
• Central updates benefit all consumers immediately

🧠 Automation as a First-Class Capability

Automation is not limited to predefined CI/CD steps. By integrating scripting capabilities (Bash, Python, or any preferred language), pipelines can:

• Execute complex decision logic based on runtime conditions
• Dynamically adapt to context (branch, environment, configuration)
• Orchestrate cross-system workflows spanning multiple tools and APIs
• Perform data transformations, validations, and pre/post-processing
• Interact with external services (APIs, databases, notification systems)

This transforms pipelines from static execution sequences into programmable automation layers that can handle arbitrarily complex workflows.

🏗️ Idempotent Infrastructure with Terraform

Terraform ensures that infrastructure provisioning is consistent, repeatable, and declarative. Every environment is defined as code, and every change is tracked and versioned.

Key practices:

• Strict state management — remote state with locking to prevent conflicts
• Parameterized environments — same modules, different configurations
• Controlled apply workflows — plan → review → apply with approval gates
• Drift detection and correction — automated checks against desired state
• Module reuse — shared Terraform modules for common infrastructure patterns

🚀 Environment Bootstrapping on Demand

One of the most powerful capabilities is the ability to create complete environments directly from the pipeline — no tickets, no waiting, no manual steps.

This includes:

• Cloud resource provisioning (compute, storage, networking)
• Service configuration and initialization
• Identity and access setup (service accounts, roles, permissions)
• Cross-repository orchestration for dependent services
• Configuration injection and secret management

The result: A self-service platform experience where teams can provision fully functional environments (Dev, Test, Staging, Prod) without manual intervention.

From Pipeline to Platform

The real shift is conceptual, not just technical.

Pipelines are no longer just execution units — they become:

This approach reduces the gap between development workflows and infrastructure operations, aligning both under a unified automation model. Developers don’t need to understand the underlying complexity — they push code, and the platform handles the rest.

Current Jobs & Capabilities

The following automation jobs are currently implemented and operational:

Roadmap: What’s Coming Next

This platform is under active development. Here’s a look at what we’re working on and planning:

🔜 Short-term Improvements

• Enhanced rollback automation — automated rollback jobs triggered on deployment failures, with state snapshot recovery
• Pipeline analytics dashboard — centralized visibility into pipeline execution times, failure rates, and resource consumption
• Parameterized environment teardown — automated cleanup of ephemeral environments after a configurable TTL

🛣️ Planned Jobs & Features

• Policy-as-Code integration — embedding OPA (Open Policy Agent) or Sentinel policies directly into the pipeline to enforce compliance before deployment
• Secrets rotation automation — automated rotation of service account keys and certificates with zero-downtime transitions
• Database migration orchestration — coordinated schema migrations across environments with validation checkpoints
• Cost estimation job — pre-apply Terraform cost analysis using tools like Infracost, with budget threshold alerts
• Security scanning integration — SAST, DAST, and container image scanning as mandatory pipeline stages
• Ephemeral preview environments — spin up full environments per merge request for review and testing, with automatic teardown on merge

🔭 Long-term Vision

• Event-driven pipeline triggers — reactive architectures where pipelines respond to cloud events (not just Git pushes)
• Multi-cloud orchestration — extending the framework to provision and coordinate across AWS, GCP, and Azure from a single pipeline
• Self-healing infrastructure — automated remediation jobs that detect drift and restore desired state without human intervention
• Platform API layer — exposing pipeline capabilities through an internal API, enabling other tools and systems to trigger automation programmatically
• AI-assisted pipeline optimization — leveraging ML models to predict failures, optimize resource allocation, and suggest pipeline improvements

💡 Each new job and feature will be documented here as it becomes available. The goal is to build a living platform that grows with the team’s needs.

Current Limitations and Considerations

No architecture is without trade-offs. Key challenges we’re actively addressing include:

These aspects require careful design as the platform scales, and they inform our roadmap priorities.

Looking Forward

The trajectory is clear: pipelines are evolving into platform primitives.

In the near future, we can expect:

• 🏛️ Deeper integration with policy engines for automated governance
• ⚡ Event-driven and reactive pipeline architectures
• 🔗 Tighter coupling with platform APIs and service meshes
• 🌫️ Increased use of ephemeral environments for testing and review
• 🪪 Standardization of federated identity patterns across CI/CD platforms
• 🤖 AI-augmented operations for predictive scaling and anomaly detection

Organizations that embrace this shift early will gain significant advantages in scalability, security, and operational efficiency.

Closing Thoughts

Moving beyond traditional CI/CD requires rethinking the role of automation pipelines.

When combined with federated identity, Infrastructure as Code, and programmable automation, pipelines become a powerful abstraction layer for building secure, scalable, and reusable platforms.

This work is actively evolving. We’re building in the open, iterating on real-world feedback, and continuously expanding the platform’s capabilities. If you’re interested in following the progress or discussing similar approaches, I’d love to connect.

The direction is clear — and we’re just getting started. 🚀

Last updated: March 2026

https://github.com/leobip/monitoring.git

Welcome! 👋 This project sets up a local monitoring stack based on Prometheus, Grafana, and Kafka (with Kafka UI), using Helm charts and persistent volumes for durability.

Whether you’re experimenting with Kubernetes, developing custom controllers, or just want to see your cluster’s activity in real time — this guide has got you covered. By the end, you’ll have a working environment where:

Prometheus collects metrics from your apps and infrastructure 🧲

Grafana helps you visualize those metrics with beautiful dashboards 📊

Kafka acts as a telemetry backbone, and Kafka-UI lets you explore the events flowing through it 🔄

This setup runs entirely on your local machine, making it ideal for testing and development — no cloud account or external services required!

🚀 What You’ll Get

Once deployed, your local monitoring stack will include:

✅ A Prometheus instance, scraping metrics on port 30090

✅ A Grafana dashboard, accessible at localhost:30095

✅ A Kafka broker with persistent volumes

✅ Kafka UI at localhost:30096 to inspect topics and messages

✅ A health check script to ensure everything is up and running

📦 Prometheus + Grafana

We’ll use the official Helm charts from Bitnami and Prometheus Community, with a few tweaks for local development and persistence. See values files for config details.

🧱 Kafka + Kafka UI

This section helps you install Kafka in plaintext mode, along with a lightweight UI to browse topics and messages.

Persistent volumes are enabled so your topics and messages stick around across Minikube restarts.

🧱 Folder Structure

monitoring/
├── deploy-all.sh # Script to install all components
├── pv/ # Persistent volume manifests
│ ├── kafka-pv.yaml
│ ├── prometheus-pv.yaml
│ └── grafana-pv.yaml
└── values/ # Helm values for each component
  ├── kafka-values.yaml
  ├── kafka-ui-values.yaml
  ├── prometheus-values.yaml
  └── grafana-values.yaml

🛠️ Prerequisites

Make sure you have the following installed:

• Minikube
• kubectl
• Helm

This setup assumes you’re running Kubernetes locally with Minikube.

🚀 Installation

1.– Start Minikube

minikube start --memory=4g --cpus=2

2.- Add Helm repositories

• This step is added in the script: Just uncomment de section

3.- Run the install script

cd monitoring
chmod +x deploy-all.sh
./deploy-all.sh

• This script will:
  • Create a monitoring namespace.
  • Apply persistent volumes from pv/.

📋 Access to Monitoring Tools

✅ Additional Notes

• Minikube IP: 192.168.49.2 (verify with minikube ip if needed)
• Namespace: monitoring
• PVCs applied: grafana-pvc, kafka-pv, prometheus-pvc

🎯 Verify Your Setup

Let’s make sure everything is working! You’ll check that Prometheus, Grafana, Kafka, and Kafka UI are all running and accessible via NodePorts.

🔍 Accessing Tools from Host (Minikube + Docker on macOS)

• By default, services exposed via NodePort in Minikube may not be directly accessible from your host when using the Docker driver on macOS. This is due to networking limitations: the NodePort is exposed inside the Minikube VM/container, not on your host machine’s network.

Get the name of the tools pods

❯ kubectl get svc -n monitoring
NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
grafana                               NodePort    10.102.51.68     <none>         80:30095/TCP                 29m
kafka                                 ClusterIP   10.100.118.216   <none>         9092/TCP,9095/TCP            46m
kafka-controller-0-external           NodePort    10.109.227.109   192.168.49.2   9094:30092/TCP               46m
kafka-controller-1-external           NodePort    10.97.149.130    192.168.49.2   9094:30093/TCP               46m
kafka-controller-2-external           NodePort    10.99.194.34     192.168.49.2   9094:30094/TCP               46m
kafka-controller-headless             ClusterIP   None             <none>         9094/TCP,9092/TCP,9093/TCP   46m
kafka-jmx-metrics                     ClusterIP   10.99.29.148     <none>         5556/TCP                     46m
prometheus-alertmanager               ClusterIP   10.103.180.130   <none>         9093/TCP                     46m
prometheus-alertmanager-headless      ClusterIP   None             <none>         9093/TCP                     46m
prometheus-kube-state-metrics         ClusterIP   10.102.171.116   <none>         8080/TCP                     46m
prometheus-prometheus-node-exporter   ClusterIP   10.97.14.115     <none>         9100/TCP                     46m
prometheus-prometheus-pushgateway     ClusterIP   10.101.189.12    <none>         9091/TCP                     46m
prometheus-server                     NodePort    10.104.67.195    <none>         80:30090/TCP                 46m

Example

kubectl get svc -n monitoring grafana

NAME      TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
grafana   NodePort   10.102.51.68   <none>        80:30095/TCP   34m


kubectl get svc -n monitoring prometheus-server

NAME         TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
prometheus   NodePort   10.98.27.101   <none>        9090:31090/TCP   45m


kubectl get svc -n monitoring kafka-ui

NAME       TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
kafka-ui   NodePort   10.96.220.89   <none>        8080:30096/TCP   19m

# ⚠️ IP may change on restart (check again)
minikube ip
192.168.49.2

• You might expect curl <http://192.168.49.2:30095> to work, but it doesn’t respond.

🧪 Option 1: minikube service (Temporary)

# Grafana
minikube service grafana -n monitoring

# Prometheus
minikube service prometheus-server -n monitoring

# Kafka-ui
minikube service kafka-ui -n monitoring

• This opens a temporary proxy and shows a localhost URL like:

# Grafana
|------------|---------|-------------|---------------------------|
| NAMESPACE  |  NAME   | TARGET PORT |            URL            |
|------------|---------|-------------|---------------------------|
| monitoring | grafana | service/80  | http://192.168.49.2:30095 |
|------------|---------|-------------|---------------------------|
🏃  Starting tunnel for service grafana.
|------------|---------|-------------|------------------------|
| NAMESPACE  |  NAME   | TARGET PORT |          URL           |
|------------|---------|-------------|------------------------|
| monitoring | grafana |             | http://127.0.0.1:56851 |
|------------|---------|-------------|------------------------|
🎉  Opening service monitoring/grafana in default browser...
❗  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.


# Prometheus
|------------|-------------------|-------------|---------------------------|
| NAMESPACE  |       NAME        | TARGET PORT |            URL            |
|------------|-------------------|-------------|---------------------------|
| monitoring | prometheus-server | http/80     | http://192.168.49.2:30090 |
|------------|-------------------|-------------|---------------------------|
🏃  Starting tunnel for service prometheus-server.
|------------|-------------------|-------------|------------------------|
| NAMESPACE  |       NAME        | TARGET PORT |          URL           |
|------------|-------------------|-------------|------------------------|
| monitoring | prometheus-server |             | http://127.0.0.1:56409 |
|------------|-------------------|-------------|------------------------|
🎉  Opening service monitoring/prometheus-server in default browser...
❗  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.


# kafka
|------------|----------|-------------|---------------------------|
| NAMESPACE  |   NAME   | TARGET PORT |            URL            |
|------------|----------|-------------|---------------------------|
| monitoring | kafka-ui | http/8080   | http://192.168.49.2:30096 |
|------------|----------|-------------|---------------------------|
🏃  Starting tunnel for service kafka-ui.
|------------|----------|-------------|------------------------|
| NAMESPACE  |   NAME   | TARGET PORT |          URL           |
|------------|----------|-------------|------------------------|
| monitoring | kafka-ui |             | http://127.0.0.1:64903 |
|------------|----------|-------------|------------------------|

• ✅ Works immediately, opens browser
  • ❗ Needs terminal to stay open (as it runs a local tunnel)
  • ❗ Not script-friendly or persistent

persistent

🛠 Option 2: kubectl port-forward (Persistent while running)

• You can forward the Grafana service to a local port
  • With Lens, Openlens, K9s, etc
  • Or via kubectl cmd in terminal

kubectl port-forward -n monitoring svc/grafana 30095:80

kubectl port-forward -n monitoring svc/prometheus 9090:9090

kubectl port-forward svc/kafka-ui 8080:8080 -n monitoring

• NOTE: Yopu have to stop the temporary proxy with ctrl-c before stop minikube, and execute again on restart

• Then visit (In this example):

# grafana
http://localhost:30095

# prometheus
http://localhost:9090

# kafka
http://localhost:9093

• Login
  • Grafana:
    • user: admin
    • password: admin***
• ✅ Works reliably
  • ❗ Still requires the terminal to stay open
  • ❗ Better suited for dev workflows, or when using tools like Lens/K9s which manage this automatically

🛡 Option 3: minikube tunnel (Recommended for real external access)

• Only if you define type: as LoadBalancer instead of NodePort

minikube tunnel

• Exposes NodePort and LoadBalancer services to your macOS host.
• Runs in background (but requires admin privileges).
• Makes the minikube ip + NodePort combination work:

curl http://192.168.49.2:30095
...

• ✅ Best if you want persistent access via actual cluster IP
• ⚠️ You’ll need to keep the tunnel running in a terminal

Summary

Tools Summary

🔄 Stopping and Restarting Minikube Safely

♻️ Minikube Lifecycle (Shutdown / Restart)

To safely shut down and restart your monitoring stack without losing data or encountering errors:

✅ Stop Minikube

• Use minikube stop instead of deleting the cluster:
  • This safely shuts down the VM/container.
  • PVCs and all service configurations remain intact.

minikube stop

✅ Start Again Later

• This restores the full state, including your deployed services, PVCs, and Helm releases.
  • All NodePorts and persistent data remain available.

minikube start

⚠️ Do Not Use

• ❌ This deletes all volumes, pods, secrets, configs — use only if you want a clean reset.

minikube delete

🧪 Check Status

kubectl get pods -n monitoring

• If pods don’t come up correctly (e.g., CrashLoopBackOff), you may need to:
  • Reapply deploy-all.sh

  • Re-check Minikube disk availability with:

    minikube ssh
    df -h
    

🔒 Persistent Volumes & Restarting Notes

🔁 Optional: Restart deploy-all.sh (if needed)

• You can safely re-run the script to reapply Helm charts and PVCs:
  • 💡 Helm is idempotent — it will upgrade existing releases without data loss if PVCs exist.

./deploy-all.sh

📁 Tip: Back Up Persistent Data (Optional)

• To snapshot your PVCs before restarting or for backup purposes:

kubectl get pvc -n monitoring

• For example:

kubectl cp monitoring/prometheus-server-0:/opt/bitnami/prometheus/data ./backup-prometheus-data

🧠 Final Tip: Automate Health Checks (Optional)

To quickly check if your monitoring stack is up and running, you can either:

✅ Option A: Use the health check script (recommended)

• Run the provided script to verify key components like Prometheus, Grafana, Kafka and Kafka-UI:

./check-health.sh

• Response

❯ ./check-health.sh

⏳ Checking health of monitoring components in namespace: monitoring
🔍 prometheus-server...
deployment "prometheus-server" successfully rolled out
✅ prometheus-server is healthy
🔍 grafana...
deployment "grafana" successfully rolled out
✅ grafana is healthy
🔍 kafka-ui...
deployment "kafka-ui" successfully rolled out
✅ kafka-ui is healthy
🔍 kafka-controller...
statefulset rolling update complete 3 pods at revision kafka-controller-98bc6557b...
✅ kafka-controller is healthy
✅ Health check completed.

• If components are not found or in a bad state, the script will print warnings accordingly.
• You can edit the script to match the names of your deployments or statefulsets, depending on your YAMLs.

🔍 Option B: Check manually with kubectl

If you prefer manual inspection or want to verify specific resources:

• List all pods in the monitoring namespace:

kubectl get pods -n monitoring

• You should see something like:

NAME                                                READY   STATUS    RESTARTS        AGE
grafana-57554dd88-rc8z4                             1/1     Running   0               3h11m
kafka-controller-0                                  1/1     Running   0               175m
kafka-controller-1                                  1/1     Running   0               175m
kafka-controller-2                                  1/1     Running   0               175m
kafka-ui-5448964747-ds2bd                           1/1     Running   0               171m
prometheus-alertmanager-0                           1/1     Running   1 (4h59m ago)   24h
prometheus-kube-state-metrics-7f796b7d44-89mjd      1/1     Running   1 (4h59m ago)   24h
prometheus-prometheus-node-exporter-cltc4           1/1     Running   1 (4h59m ago)   24h
prometheus-prometheus-pushgateway-d4f8cb767-nwtn9   1/1     Running   1 (4h59m ago)   24h
prometheus-server-79798b4ff6-7g55g                  2/2     Running   2 (4h59m ago)   24h
...

• Check services and their ports:

kubectl get svc -n monitoring

• Look for NodePort services exposing the UIs:

NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
grafana                               NodePort    10.104.174.27    <none>         80:30095/TCP                 3h11m
kafka                                 ClusterIP   10.106.201.77    <none>         9092/TCP,9095/TCP            175m
kafka-controller-0-external           NodePort    10.105.143.201   192.168.49.2   9094:30092/TCP               175m
kafka-controller-1-external           NodePort    10.101.82.105    192.168.49.2   9094:30093/TCP               175m
kafka-controller-2-external           NodePort    10.97.107.152    192.168.49.2   9094:30094/TCP               175m
kafka-controller-headless             ClusterIP   None             <none>         9094/TCP,9092/TCP,9093/TCP   175m
kafka-ui                              NodePort    10.100.56.227    <none>         8080:30096/TCP               171m
prometheus-alertmanager               ClusterIP   10.103.180.130   <none>         9093/TCP                     24h
prometheus-alertmanager-headless      ClusterIP   None             <none>         9093/TCP                     24h
prometheus-kube-state-metrics         ClusterIP   10.102.171.116   <none>         8080/TCP                     24h
prometheus-prometheus-node-exporter   ClusterIP   10.97.14.115     <none>         9100/TCP                     24h
prometheus-prometheus-pushgateway     ClusterIP   10.101.189.12    <none>         9091/TCP                     24h
prometheus-server                     NodePort    10.104.67.195    <none>         80:30090/TCP                 24h

• Then, access the dashboards using http://<minikube-ip>:<nodeport>. For example:
  • Grafana: http://localhost:30095
  • Prometheus: http://localhost:30090
  • Kafka UI: http://localhost:30096
• Use minikube ip to get your cluster IP if needed.

🌳 Branching Strategy

We adopt a simplified Git Flow–inspired model:

• main branch → Always reflects the latest stable production-ready code.
• dev branch → Integration branch for ongoing development.
• feature/* branches → Temporary branches for new features, merged back into dev.
• hotfix/* branches → For urgent fixes, branched directly from main, then merged back into both main and dev.

Example Workflow

gitGraph
   commit id: "Init"
   branch dev
   checkout dev
   commit id: "Feature A start"
   branch feature/A
   commit id: "WIP A1"
   commit id: "WIP A2"
   checkout dev
   merge feature/A id: "Merge A"
   commit id: "Stabilization"
   checkout main
   merge dev id: "Release v1.0.0"
   branch hotfix/urgent
   commit id: "Hotfix"
   checkout main
   merge hotfix/urgent id: "Release v1.0.1"
   checkout dev
   merge hotfix/urgent

## 📌 Semantic Versioning (SemVer)

We use Semantic Versioning 2.0.0 format:

```bash
MAJOR.MINOR.PATCH

• MAJOR → Breaking changes (e.g., API change, backward-incompatible refactor).
• MINOR → New features, backward-compatible.
• PATCH → Bug fixes, backward-compatible.

Examples

• 1.0.0 → Initial stable release.
• 1.1.0 → Adds new features without breaking existing functionality.
• 1.1.1 → Fixes a bug without changing functionality.

🏷 Tagging Releases in Git

Each release is tagged with its SemVer version:

# Tagging a release
git tag -a v1.0.0 -m "Release v1.0.0 - Initial stable release"
git push origin v1.0.0

This allows:

• CI/CD pipelines to build artifacts based on tags.
• Traceability of deployments.
• Easy rollback to previous versions.

🔗 Integration with CI/CD

• Development branch (dev) → triggers tests & static analysis (e.g., SonarQube).
• Main branch (main) → triggers build + deployment pipeline.
• Tags (vX.Y.Z) → trigger release pipelines (e.g., publishing Docker images, Helm charts).

✅ Conclusion

By combining a clear branching strategy with Semantic Versioning, we ensure:

• Predictable release cycles.
• Traceability of features and fixes.
• Alignment between Git workflow and CI/CD pipelines.

This model scales from small projects to enterprise environments and integrates seamlessly with tools like SonarQube, GitHub Actions, and ArgoCD.

This article serves as the central hub of the series — each tool (e.g., SonarQube, ArgoCD, Monitoring) will have its own dedicated post with installation details, while here we’ll explain how everything integrates together.

🗂 Planned Components

• 🔍 Code Analysis (SonarQube) – Static code analysis for code quality.
• 📝 Linting (SonarLint for IDEs) – Consistent coding standards in real-time.
• 🔄 Version Control (GitHub) – Branches, PRs, tags, semantic versioning (we’ll link a dedicated article).
• ⚡ CI/CD Pipelines (GitHub Actions) – Automated build & test pipelines.
• 🚀 Deployment (ArgoCD) – GitOps-based application delivery.
• 📊 Monitoring (Prometheus, Grafana) – Observability for apps.

📂 Project Structure

Here’s the proposed folder layout for our environment:

local-dev-environment/
│
├── sonarqube/                  # SonarQube setup and configuration
│   ├── conf/                   # SonarQube config (sonar.properties, etc.)
│   ├── data/                   # Persistent data storage
│   ├── logs/                   # Log files
│   └── extensions/             # Plugins & extensions
│
├── code-examples/              # Sample code for analysis & testing
│   └── python/
│       └── api-requests.py
│
├── tests/                      # Example unit tests
│   └── test_example.py
│
├── .github/
│   ├── workflows/
│   │   └── sonarqube-analysis.yml  # Pipeline  
│   └── actions-runner/             # Self-hosted GitHub Actions Runner
│       └── run.sh                  # Script to start the runner
│
├── docker-compose.yaml         # Compose file for multiple services
├── README.md                   # Project documentation
└── requirements.txt            # Dependencies
...
... (in development)

Steps

• Create the folders and initialize the repository
• You can initialize the repository by running git init in the root folder of local-dev-environment.
• Push the code to your GitHub repository and link it here: Project GitHub Repository

This guide will start with SonarQube, a powerful tool for static code analysis, and expand as we integrate more tools.

🔍 Static Code Analysis with SonarQube

We start our environment with SonarQube, a powerful static analysis tool that detects bugs, security vulnerabilities, and code smells.

Once SonarQube is running locally (via docker-compose), we can integrate it into our pipeline so that every push to the repository gets analyzed automatically.

• 👉 Detailed installation guide: SonarQube Setup Article

⚡ GitHub Actions – SonarQube Analysis Pipeline

As a first CI/CD integration, let’s configure a GitHub Actions workflow to run SonarQube scans on our code. This pipeline runs on the dev branch — a common branching strategy where:

• dev → integration branch for ongoing development
• main → stable production-ready branch
• feature/* → temporary branches for new features

We’ll create a separate article on branching models, semantic versioning, and release workflows (to keep this guide focused).

• 👉 Detailed installation guide: Branching & Semantic Versioning Article

🔧 Setting Up GitHub Actions

1. Navigate to your repository on GitHub.
2. Click on the Actions tab in the repository menu.
3. If this is your first time, you’ll be prompted to configure a new workflow. Click “Set up this workflow yourself”.
4. GitHub will open a YAML editor where you can define your first workflow.

5. Inside your repository, make sure you have the following directory structure:

   .github/
     └── workflows/
         └── sonarqube-analysis.yml
   

This file will contain the pipeline configuration for SonarQube analysis.

🔑 Add SonarQube Token to GitHub Secrets

For the workflow to authenticate with SonarQube, you need a token:

• Generate a token in SonarQube:
  • Go to My Account → Security → Generate Tokens.
  • Copy the generated token (you will not be able to see it again).
• Add it to your GitHub repository secrets:
  • Open your GitHub repository.
  • Go to Settings → Secrets and variables → Actions.
  • Click New repository secret.
  • Name it SONAR_TOKEN and paste the value from SonarQube.
• Workflow File: .github/workflows/sonarqube-analysis.yml

name: SonarQube Analysis

on:
  push:
    branches:
      - dev
  # Uncomment below if you want to analyze PRs into main
  # pull_request:
  #   branches:
  #     - main

jobs:
  sonarQube:
    runs-on: self-hosted

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run SonarScanner
        run: |
          sonar-scanner \
            -Dsonar.projectKey=chronos-desktop-app \
            -Dsonar.sources=. \
            -Dsonar.host.url=http://localhost:9001 \
            -Dsonar.login=$

🖥️ Setting Up the Actions Runner

Since we’re running SonarQube locally, the pipeline needs a self-hosted GitHub Actions runner.

Steps to Add Actions Runner

• Create the folder:

mkdir -p .github/actions-runner

• Inside, add the script run.sh:

#!/bin/bash
cd .github/actions-runner
./run.sh

# Make it executable:
chmod +x .github/actions-runner/run.sh

# Start the runner before pushing code:
./github/actions-runner/run.sh

⚠️ Important Notes

✅ SonarQube must be running → Since we deployed it via Docker Compose, containers will auto-restart after a reboot (unless stopped manually in Docker Desktop). You can always check in Docker Desktop or via docker ps.

✅ Start the runner before committing/pushing → If the runner isn’t running, GitHub won’t detect the workflow and the pipeline won’t execute.

✅ Branch strategy → For now, we trigger analysis only on dev. Later, we’ll extend this to main and release workflows.

🔑 Key Points

• runs-on: self-hosted → The job runs on a self-hosted runner (needed since we use local SonarQube).
• SONAR_TOKEN → Stored in GitHub Secrets, generated from SonarQube.
• Branching strategy → For now, we run scans on dev. Later, we may extend it to main or PRs.

This ensures every code change on dev is scanned, keeping quality checks aligned with our development workflow.

🚀 Next Steps

• Expand pipelines to include tests, builds, and deployments.
• Add ArgoCD to migrate and manage SonarQube in Kubernetes.
• Extend analysis pipelines for main branch with semantic versioning & release tags.
• Integrate monitoring to visualize the health of our apps.

This is just the first building block of our developer ecosystem. With each article, we’ll add another piece until the full puzzle comes together. 🧩

Introduction

In this post, Python Tools Library, I’ll be collecting and sharing tools that I’ve developed to make my day-to-day work easier, cover specific needs, or simply explore ideas that might simplify common tasks.

The goal is to share knowledge in a practical way. All tools will be stored in the same GitHub repository, and the blog will indicate which tool was added most recently so readers can easily track updates.

JSon Full Search

Description

As the name suggests, this is a function designed to parse a JSON file and extract the value of a given key. It works recursively, which means it can traverse nested dictionaries and retrieve either a single value or an entire dictionary depending on the requested key.

This makes it especially useful when working with deeply nested JSON structures. Here I’ll explain how to use it and document future improvements.

Example JSON

{
    "name": "John Doe",
    "age": 30,
    "address": {
        "street": "123 Main St",
        "city": "Anytown",
        "state": "CA",
        "country": {
            "name": "United States",
            "code": "US"
        }
    },
    "email": "john.doe@example.com",
    "phone_numbers": [
        {
            "type": "home",
            "number": "555-555-5555"
        },
        {
            "type": "work",
            "number": "555-555-5556"
        }
    ],
    "employment": {
        "job_title": "Software Engineer",
        "department": {
            "name": "Engineering",
            "location": {
                "building": "HQ",
                "floor": 5
            }
        }
    }
}

Usage

From the example above, you can extract the value of the key city: “Anytown”. You can also extract the full nested dictionary address: { … }.

Pending features

• Counter for cases with duplicate keys (e.g., multiple name fields).
• Key identifiers to handle repeated keys.

Features

• Tecnology: Python

🔗 GitHub Repository: python-custom-tools

SonarQube & SonarLint

Repository Reference

All the configuration files, including the docker-compose.yaml used in this article, are available in our repository:

👉 local-dev-env Repository

This repository is intended to become the central place for our local development environment setup, where we will keep adding tools such as:

• SonarQube – Static code analysis (this article).
• GitHub Actions Pipelines – CI/CD workflows.
• ArgoCD – GitOps-based application deployment.
• Monitoring stack – Observability for apps.
• And more developer tools…

Each tool will have its own dedicated article with installation details, and the central article Local Dev Environment will explain how they all integrate together into a complete workflow.

What is SonarQube?

SonarQube is a powerful static code analysis tool that helps developers identify bugs, security vulnerabilities, and code smells in their projects. It provides detailed insights to improve code quality and maintainability.

SonarQube is available in different editions:

• Community Edition (Free) – Open-source version with essential static analysis features.
• Developer Edition – Adds advanced language support and branch analysis.
• Enterprise Edition – Includes portfolio management and governance features.
• Data Center Edition – High availability and scalability for large teams.

For this guide, we will use the Community Edition.

What is SonarLint?

SonarLint is an IDE plugin that provides real-time linting and code analysis. It helps developers catch issues early in the development process, ensuring consistent and high-quality code. It can be confiugured to work alone or with connection to SonarQube profiles, It functions as an extension of SonarQube when connected to the server.

Connection between SonarLint and SonarQube

• SonarLint can operate in two modes:
  • Standalone mode: Works independently in the IDE.
  • Connected mode: Synchronizes with a SonarQube server to share rules and configurations.
• To connect SonarLint with SonarQube:
  • Ensure that SonarQube is running.
  • Install the SonarLint plugin in your IDE.
  • Add the SonarQube URL in the SonarLint configuration.
  • Authenticate with a SonarQube token.

Database Support in SonarQube

Embedded Database (H2)

By default, SonarQube Community Edition comes with an embedded H2 database. However, this database is only intended for evaluation and personal/local usage, as it is not recommended for production due to size & data scalability limitations.

Supported External Databases

For a stable and production-ready deployment, SonarQube supports the following databases

• PostgreSQL (Recommended)
• Microsoft SQL Server
• Oracle Database

SonarQube Database Configuration Guides

• SonarQube Database Configuration Guide

Installing SonarQube Locally

• Prerequisite: Before setting up SonarQube, ensure that Docker & docker-compose is installed on your machine. You can find the complete installation guide on the official Docker website, Docker Installation Guide: https://docs.docker.com/engine/install/

• SonarQube Installation

To deploy SonarQube locally, we will use Docker Compose. This approach allows for future integration of additional tools and services within the local development environment. Using Docker Compose simplifies service configuration and management through a docker-compose.yaml file located in the project’s root directory.

Docker significantly simplifies the process of running SonarQube without requiring complex manual configurations. For reference, the SonarQube page on Docker Hub (https://hub.docker.com/_/sonarqube) provides links to repositories with example Dockerfile and docker-compose.yaml configurations, and instructions to install and run SonarQube with simplest command like:

docker run --name sonarqube-custom -p 9000:9000 sonarqube:community

You can then browse to http://localhost:9000 or http://host-ip:9000 in your web browser to access the web interface.

Bonus: HELM - Installation with PostgreSQL Included

For Kubernetes users, SonarQube can be installed using Helm with a PostgreSQL database included. Check out the official Helm package: (here you can find different versions at Artifact Hub) 🔗 SonarQube Helm Chart

Folder Structure

local-dev-environment/
│
├── sonarqube/                  # SonarQube setup
│   ├── conf/                   # Configuration files
│   ├── data/                   # Data storage
│   ├── logs/                   # Log files
│   ├── extensions/             # Plugins and extensions
│
├── docker-compose.yaml         # Docker Compose for multiple services
...

• docker-compose.yaml (at project root)

services:
  sonarqube:
    image: sonarqube:community # We are using the latest community version, it could also be the lts-community -(Long Term Support)
    restart: unless-stopped  # 🔄 Automatically restarts after a system reboot
    depends_on:
      - sonar_db
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://sonar_db:5432/sonar
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: sonar
    ports:
      - "9001:9000"
    volumes:
      - sonarqube_conf:/opt/sonarqube/conf
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
      - sonarqube_temp:/opt/sonarqube/temp

  sonar_db:
    image: postgres:13
    restart: unless-stopped  # 🔄 Automatically restarts after a system reboot
    environment:
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: sonar
      POSTGRES_DB: sonar
    volumes:
      - sonar_db:/var/lib/postgresql
      - sonar_db_data:/var/lib/postgresql/data

volumes:
  sonarqube_conf:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_logs:
  sonarqube_temp:
  sonar_db:
  sonar_db_data:

Automatic Backup of the SonarQube Database (Optional)

Even though we configured restart: unless-stopped, ensuring that data persists after a reboot, in our local environment, it’s good practice to have a backup strategy. Below is a solution using a backup service.

Manual DB Backup

• To back up the PostgreSQL database:

docker exec -t postgres pg_dumpall -c -U sonar > backup.sql

• To restore:

docker exec -i postgres psql -U sonar -d sonarqube < backup.sql

Adding a Backup Service

• Add this code to the docker-compose.yaml

  sonar_backup:
    image: postgres:13
    depends_on:
      - sonar_db
    volumes:
      - sonarqube_data:/opt/sonarqube/data
    entrypoint: ["/bin/sh", "-c", "while true; do /opt/sonarqube/data/backup_db.sh; sleep 86400; done"]

• Backup Script

Create the following script inside sonarqube/data/backup_db.sh:

#!/bin/bash

# Configuration
BACKUP_DIR="/opt/sonarqube/data/backups"
TIMESTAMP=$(date +"%Y-%m-%d_%H-%M-%S")
BACKUP_FILE="$BACKUP_DIR/sonarqube_db_$TIMESTAMP.sql"

# Create backup directory if it does not exist
mkdir -p $BACKUP_DIR

# Perform PostgreSQL backup
PGPASSWORD="sonar" pg_dump -h sonar_db -U sonar -d sonar > $BACKUP_FILE

# Clean up old backups (optional, keep only the last 5 backups)
ls -tp $BACKUP_DIR | grep -v '/$' | tail -n +6 | xargs -I {} rm -- "$BACKUP_DIR/{}"

echo "Backup completed: $BACKUP_FILE"

• Grant Execution Permission
• Run the following command to make the script executable:

chmod +x sonarqube/data/backup_db.sh

Conclusion

• SonarQube and PostgreSQL are configured with persistent storage.
• Containers automatically restart unless manually stopped.
• A backup service is set up to create database backups automatically.

This setup ensures a robust SonarQube environment for local development. 🚀

Running SonarQube

Once the files are in place, follow these steps to start SonarQube:

• Build the SonarQube image

docker-compose build

• Start the SonarQube container

docker-compose up -d

• Access SonarQube UI
  • Open http://localhost:9001 in your browser.
  • 
• Login Credentials
  • Username: admin
  • Password: admin

Installing and Configuring SonarQube for IDE (fromerly SonarLint)

Installation

To install SonarLint in your IDE

• VS Code: Install the “SonarLint” extension from the Extensions Marketplace
• IntelliJ IDEA: Install the “SonarLint” plugin from the Plugins Marketplace.
• Eclipse: Install the “SonarLint” plugin from the Eclipse Marketplace.

Vs-Code Example

Using SonarLint in Standalone Mode

SonarLint can work independently without connecting to a SonarQube server. In this mode, it provides static analysis using its built-in rule set.

For example, after installing SonarLint in VS Code:

• Open a project.
  • SonarLint will automatically scan the files for issues.
  • Hover over a warning to view explanations and possible fixes.

This is useful when you want quick feedback without setting up a full SonarQube instance.

Configuration in Connected Mode

To connect SonarLint to SonarQube:

Open the SonarLint settings in your IDE.

Select “Connect to SonarQube or SonarCloud.”

Enter the SonarQube server URL (e.g., http://localhost:9000).

Authenticate using a SonarQube token. (Or allow access from your Sonarqube instance)

Select the project to synchronize the analysis rules.

Example of SonarLint in Action

Open a code file in your IDE.

If there are issues, SonarLint will highlight them with warnings and suggestions.

Hover over an issue to see details and possible fixes.

If connected to SonarQube, the rules from the server will be applied in real-time.

With this setup, you have a functional SonarQube environment with persistence and an external database. Additionally, SonarLint enhances your development experience by providing real-time feedback. Now it’s time to analyze your code!

Next Steps

In this article, we focused on installing and configuring SonarQube with Docker Compose.
This is part of a broader series about building a local development & testing environment.

In the following articles, we will integrate additional tools such as GitHub Actions pipelines, ArgoCD, and monitoring solutions.
When we introduce ArgoCD, we will also show how to migrate SonarQube from Docker Compose to Kubernetes and manage it through GitOps.

Stay tuned — our development environment will keep evolving step by step! 🚀