Hola! Soy

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Contáctame

Sobre Mí

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Mis Habilidades

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automatización de Procesos

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Sistemas Personalizados

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

Mi Misión

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

🚀

Democratizar la Tecnología

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

💡

Unir Informática y Economía

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

🎯

Crear Soluciones a Medida

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Transforma Tu Negocio con la Tecnología

Dicembre 2024

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

💻 Linguaggi & Tecnologie

☕Java

🐍Python

📜JavaScript

🅰️Angular

⚛️React

🔷TypeScript

🗄️SQL

🐘PHP

🎨CSS/SCSS

🔧Node.js

🐳Docker

🌿Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contáctame

¿Tienes un proyecto en mente? ¡Hablemos! Completa el formulario y te responderé pronto.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Introducción: CI/CD para Desarrolladores Frontend

Todo desarrollador frontend tarde o temprano se enfrenta a la misma pregunta: ¿cómo puedo automatizar el proceso de build, test y despliegue de mi aplicación? La respuesta moderna se llama CI/CD (Integración Continua / Despliegue Continuo), y GitHub Actions representa hoy la herramienta más accesible y potente para implementarlo directamente en el repositorio del proyecto.

En este primer artículo de la serie DevOps para Desarrolladores Frontend, construiremos desde cero un pipeline completo para una aplicación Angular: desde el primer workflow de integración continua hasta el despliegue automático en producción. Cada concepto se explica con ejemplos prácticos y código listo para usar.

Qué Aprenderás en Este Artículo

Los conceptos fundamentales de GitHub Actions: workflow, job, step y trigger
Cómo configurar un workflow CI para Angular (install, lint, test, build)
Cómo implementar el despliegue automático en Firebase y Vercel
Estrategias de caching para acelerar los pipelines
Matrix strategy para probar en múltiples versiones de Node.js
Cómo configurar artifacts y branch protection rules
Cómo crear workflows reutilizables

1. Conceptos Fundamentales de GitHub Actions

GitHub Actions es una plataforma de automatización integrada en GitHub. Cada automatización se basa en cuatro conceptos clave que forman una jerarquía precisa:

      Jerarquía de GitHub Actions
      
          Concepto
          Descripción
          Analogía
        
          Workflow
          Un archivo YAML en .github/workflows/ que define toda la automatización
          La receta completa
        
          Job
          Un grupo de steps que se ejecuta en un runner específico
          Una fase de la receta
        
          Step
          Un comando o acción individual dentro de un job
          Una instrucción específica
        
          Trigger
          El evento que inicia el workflow (push, PR, schedule, etc.)
          El momento de comenzar

Un workflow puede contener múltiples jobs, y cada job puede contener múltiples steps. Los jobs se ejecutan en paralelo por defecto, pero pueden configurarse con dependencias para la ejecución secuencial.

Estructura de un Workflow YAML

Cada workflow reside en el directorio .github/workflows/ del repositorio. Esta es la estructura base de un archivo workflow:


# .github/workflows/ci.yml
name: CI Pipeline

# Trigger: cuándo ejecutar el workflow
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

# Variables de entorno globales
env:
  NODE_VERSION: '20'

# Los jobs a ejecutar
jobs:
  build:
    # Runner: máquina virtual donde ejecutar
    runs-on: ubuntu-latest

    # Steps del job
    steps:
      # Step 1: Checkout del código
      - name: Checkout repository
        uses: actions/checkout@v4

      # Step 2: Setup Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}

      # Step 3: Instalación de dependencias
      - name: Install dependencies
        run: npm ci

      # Step 4: Build
      - name: Build application
        run: npm run build

Los Triggers Principales

Los triggers determinan cuándo se inicia un workflow. GitHub Actions soporta decenas de eventos, pero para proyectos frontend los más utilizados son:


on:
  # En cada push a los branches especificados
  push:
    branches: [main, develop]
    paths:
      - 'src/**'
      - 'package.json'

  # En cada Pull Request hacia main
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened]

  # Ejecución programada (cron)
  schedule:
    - cron: '0 6 * * 1'  # Cada lunes a las 6:00 UTC

  # Trigger manual
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production

Atención con los Triggers en Push

El filtro paths es muy útil para evitar builds innecesarios: si solo modificas el README, no tiene sentido volver a ejecutar todo el pipeline. Sin embargo, ten cuidado de no excluir archivos críticos como angular.json o tsconfig.json que afectan la build.

2. Workflow CI Completo para Angular

Construyamos ahora un workflow de Integración Continua completo para un proyecto Angular. Este workflow ejecutará en secuencia: instalación de dependencias, linting, tests unitarios y build de producción.


# .github/workflows/ci.yml
name: Angular CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'

jobs:
  lint:
    name: Lint Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng lint

  test:
    name: Unit Tests
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng test --watch=false --browsers=ChromeHeadless --code-coverage
      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/
          retention-days: 7

  build:
    name: Production Build
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng build --configuration=production
      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
          retention-days: 3

Este workflow define tres jobs en secuencia gracias a la keyword needs: primero el lint, luego los tests, y finalmente la build. Si el lint falla, los tests no se ejecutan; si los tests fallan, la build no se inicia.

Caching Avanzado de Dependencias

La keyword cache: 'npm' en la action setup-node proporciona un caching básico. Para un control más granular, podemos usar directamente la action actions/cache:


  - name: Cache node_modules
    id: cache-npm
    uses: actions/cache@v4
    with:
      path: |
        node_modules
        ~/.npm
      key: #123;{ runner.os }}-npm-#123;{ hashFiles('package-lock.json') }}
      restore-keys: |
        #123;{ runner.os }}-npm-

  - name: Install dependencies
    if: steps.cache-npm.outputs.cache-hit != 'true'
    run: npm ci

La clave de caché usa el hash del archivo package-lock.json: cuando las dependencias no cambian, la caché se reutiliza y la instalación se omite completamente. Esto puede reducir el tiempo del pipeline en 30-60 segundos por cada ejecución.

3. Matrix Strategy: Tests Multi-Versión

La matrix strategy permite ejecutar el mismo job con combinaciones diferentes de parámetros. Para un proyecto Angular, es particularmente útil para probar en múltiples versiones de Node.js:


  test-matrix:
    name: Test on Node #123;{ matrix.node-version }}
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
      fail-fast: false
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng test --watch=false --browsers=ChromeHeadless

La opción fail-fast: false asegura que todos los jobs de la matriz se completen incluso si uno falla, permitiendo identificar todas las incompatibilidades en una sola ejecución.

Cuándo Usar la Matrix Strategy

Tests en múltiples versiones de Node.js (LTS actual y anterior)
Tests en múltiples sistemas operativos (ubuntu, windows, macos)
Build para diferentes entornos (staging, production)
Tests con diferentes versiones de navegadores

4. CD: Despliegue Automático en Firebase

Después de construir y probar la aplicación, el siguiente paso es el despliegue automático. Veamos cómo configurar el despliegue en Firebase Hosting, una de las opciones más comunes para aplicaciones Angular.


# .github/workflows/deploy.yml
name: Deploy to Firebase

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    name: Build and Deploy to Production
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build for production
        run: npm run build

      - name: Deploy to Firebase Hosting
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          channelId: live
          projectId: my-angular-project

Preview Deploy para Pull Request

Una funcionalidad potente de Firebase Hosting es la posibilidad de crear preview channels automáticos para cada Pull Request, permitiendo al equipo verificar los cambios antes del merge:


# .github/workflows/preview.yml
name: Deploy Preview

on:
  pull_request:
    branches: [main]

jobs:
  preview:
    name: Deploy Preview Channel
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build

      - name: Deploy to Preview Channel
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          projectId: my-angular-project
          # Sin channelId: crea automáticamente un preview channel

Despliegue en Vercel

Para quienes prefieren Vercel como plataforma de hosting, la configuración es igualmente sencilla:


# .github/workflows/deploy-vercel.yml
name: Deploy to Vercel

on:
  push:
    branches: [main]

env:
  VERCEL_ORG_ID: #123;{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: #123;{ secrets.VERCEL_PROJECT_ID }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Vercel CLI
        run: npm install -g vercel

      - name: Pull Vercel Configuration
        run: vercel pull --yes --environment=production --token=#123;{ secrets.VERCEL_TOKEN }}

      - name: Build with Vercel
        run: vercel build --prod --token=#123;{ secrets.VERCEL_TOKEN }}

      - name: Deploy to Vercel
        run: vercel deploy --prebuilt --prod --token=#123;{ secrets.VERCEL_TOKEN }}

5. Artifacts: Compartir Archivos entre Jobs

Los artifacts permiten compartir archivos entre diferentes jobs del mismo workflow. Esto es fundamental para separar la build del despliegue sin recompilar:


jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npx ng build --configuration=production

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: angular-dist
          path: dist/my-app/browser/
          retention-days: 1

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Download build artifact
        uses: actions/download-artifact@v4
        with:
          name: angular-dist
          path: dist/

      - name: Deploy
        run: |
          # El contenido del build está ahora en dist/
          ls -la dist/

      Buenas Prácticas para los Artifacts
      Configura siempre retention-days para no desperdiciar espacio de almacenamiento
Usa nombres descriptivos para los artifacts (angular-dist, coverage-report)
Sube solo los archivos necesarios, no todo el directorio node_modules
Para archivos muy grandes, considera la compresión antes de subir

    

6. Branch Protection Rules

Las branch protection rules de GitHub permiten imponer restricciones en los branches críticos. Cuando se combinan con los workflows CI, crean una barrera de calidad automática.

Para configurar las branch protection rules, ve a Settings > Branches > Add branch protection rule en tu repositorio GitHub. Las configuraciones recomendadas para el branch main son:

Require a pull request before merging: Impide push directos a main
Require status checks to pass before merging: Los workflows CI deben pasar
Require branches to be up to date before merging: El branch debe estar actualizado
Require conversation resolution before merging: Todos los comentarios deben estar resueltos

Para seleccionar qué status checks requerir, debes ejecutar el workflow al menos una vez. Después, los nombres de los jobs aparecerán en la lista de selección:


Status checks requeridos:
  [x] Lint Check          (del workflow CI)
  [x] Unit Tests          (del workflow CI)
  [x] Production Build    (del workflow CI)

7. Workflows Reutilizables

Cuando se gestionan múltiples repositorios con configuraciones similares, los reusable workflows evitan la duplicación del código. Un workflow reutilizable se define con el trigger workflow_call:


# .github/workflows/reusable-angular-ci.yml
name: Reusable Angular CI

on:
  workflow_call:
    inputs:
      node-version:
        description: 'Node.js version'
        required: false
        default: '20'
        type: string
      build-command:
        description: 'Build command to execute'
        required: false
        default: 'npm run build'
        type: string
    secrets:
      FIREBASE_SA:
        description: 'Firebase Service Account'
        required: false

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ inputs.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng lint
      - run: npx ng test --watch=false --browsers=ChromeHeadless
      - run: #123;{ inputs.build-command }}

Para utilizar este workflow reutilizable desde otro workflow:


# .github/workflows/ci.yml (en el repositorio que lo consume)
name: CI

on:
  push:
    branches: [main]

jobs:
  angular-ci:
    uses: my-org/shared-workflows/.github/workflows/reusable-angular-ci.yml@main
    with:
      node-version: '20'
      build-command: 'npm run build -- --configuration=production'
    secrets:
      FIREBASE_SA: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}

Ventajas de los Workflows Reutilizables

DRY: Un solo punto de mantenimiento para la lógica CI/CD
Estandarización: Todos los repositorios siguen las mismas prácticas
Versionamiento: Puedes referenciar una versión específica del workflow (@main, @v1)
Seguridad: Los secretos se pasan explícitamente, no se comparten globalmente

8. Ejemplo Completo: Pipeline End-to-End

Combinemos todos los conceptos en un pipeline completo que gestiona CI y CD con branch protection:


# .github/workflows/pipeline.yml
name: Full Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

concurrency:
  group: #123;{ github.workflow }}-#123;{ github.ref }}
  cancel-in-progress: true

env:
  NODE_VERSION: '20'

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng test --watch=false --browsers=ChromeHeadless --code-coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng build --configuration=production
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy-preview:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          projectId: my-angular-project

  deploy-production:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    needs: build
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          channelId: live
          projectId: my-angular-project

La opción concurrency en la parte superior del workflow es crucial: si haces múltiples push seguidos en el mismo branch, el workflow anterior se cancela automáticamente, ahorrando minutos de ejecución.

9. Debugging y Buenas Prácticas

Cuando un workflow falla, el debugging puede ser frustrante. Estas son las estrategias más eficaces:

Habilitar el Debug Logging

Puedes habilitar los logs de debug añadiendo secretos al repositorio:

ACTIONS_RUNNER_DEBUG = true para logs detallados del runner
ACTIONS_STEP_DEBUG = true para logs detallados de cada step

Steps Condicionales para el Debug


  - name: Debug info
    if: failure()
    run: |
      echo "Node version: $(node -v)"
      echo "NPM version: $(npm -v)"
      echo "Directory: $(pwd)"
      ls -la
      cat package.json

      Buenas Prácticas para GitHub Actions
      Usa npm ci en lugar de npm install para instalaciones determinísticas
Fija siempre las versiones de las actions (@v4 en lugar de @main)
Configura concurrency para evitar builds duplicados
Usa la caché para reducir los tiempos de ejecución
Separa los jobs para tener feedback rápido (lint falla inmediatamente, no después del build)
Usa environment para proteger los secretos de producción
Configura timeout-minutes para evitar jobs bloqueados
Monitorea el consumo de minutos de GitHub Actions en el plan de tu cuenta

    

Conclusión

En este artículo hemos construido un pipeline CI/CD completo para una aplicación Angular usando GitHub Actions. Hemos explorado los conceptos fundamentales (workflow, job, step, trigger), implementado el caching de dependencias, configurado la matrix strategy para tests multi-versión, y configurado el despliegue automático en Firebase y Vercel.

La clave del éxito con los pipelines CI/CD es la iteración progresiva: comienza con un workflow simple (lint + build), luego añade los tests, y finalmente el despliegue automático. No intentes implementar todo de una vez.

En el próximo artículo de la serie, exploraremos Docker para desarrolladores frontend, aprendiendo a containerizar una aplicación Angular con Dockerfile multi-stage y a gestionar entornos de desarrollo con Docker Compose.

Concepto	Descripción	Analogía
Workflow	Un archivo YAML en `.github/workflows/` que define toda la automatización	La receta completa
Job	Un grupo de steps que se ejecuta en un runner específico	Una fase de la receta
Step	Un comando o acción individual dentro de un job	Una instrucción específica
Trigger	El evento que inicia el workflow (push, PR, schedule, etc.)	El momento de comenzar