Hallo! Ich bin

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.

Kontaktiere Mich

Über Mich

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.

Meine Fähigkeiten

Analisi Dati & Modelli Previsionali

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

Prozessautomatisierung

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

Maßgeschneiderte Systeme

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"
  ]
};

Meine Mission

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

🚀

Technologie Demokratisieren

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.

💡

IT und Wirtschaft Vereinen

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à.

🎯

Maßgeschneiderte Lösungen Erstellen

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.

Transformieren Sie Ihr Unternehmen mit Technologie

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.

Kontaktiere Mich

Sie haben ein Projekt im Sinn? Lassen Sie uns reden! Füllen Sie das Formular aus und ich melde mich bald.

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

Einführung: CI/CD für Frontend-Entwickler

Jeder Frontend-Entwickler steht früher oder später vor derselben Frage: Wie kann ich den Build-, Test- und Deployment-Prozess meiner Anwendung automatisieren? Die moderne Antwort heißt CI/CD (Continuous Integration / Continuous Deployment), und GitHub Actions ist heute das zugänglichste und leistungsfähigste Werkzeug, um es direkt im Projekt-Repository zu implementieren.

In diesem ersten Artikel der Serie DevOps für Frontend-Entwickler bauen wir von Grund auf eine vollständige Pipeline für eine Angular-Anwendung: vom ersten Workflow der kontinuierlichen Integration bis zum automatischen Deployment in die Produktion. Jedes Konzept wird mit praktischen Beispielen und einsatzbereitem Code erklärt.

Was Sie in Diesem Artikel Lernen Werden

Die grundlegenden Konzepte von GitHub Actions: Workflow, Job, Step und Trigger
Wie man einen CI-Workflow für Angular konfiguriert (install, lint, test, build)
Wie man automatisches Deployment auf Firebase und Vercel implementiert
Caching-Strategien zur Beschleunigung der Pipelines
Matrix Strategy zum Testen auf mehreren Node.js-Versionen
Wie man Artifacts und Branch Protection Rules konfiguriert
Wie man wiederverwendbare Workflows erstellt

1. Grundlegende Konzepte von GitHub Actions

GitHub Actions ist eine in GitHub integrierte Automatisierungsplattform. Jede Automatisierung basiert auf vier Schlüsselkonzepten, die eine präzise Hierarchie bilden:

      Hierarchie von GitHub Actions
      
          Konzept
          Beschreibung
          Analogie
        
          Workflow
          Eine YAML-Datei in .github/workflows/, die die gesamte Automatisierung definiert
          Das vollständige Rezept
        
          Job
          Eine Gruppe von Steps, die auf einem bestimmten Runner ausgeführt wird
          Eine Phase des Rezepts
        
          Step
          Ein einzelner Befehl oder eine Aktion innerhalb eines Jobs
          Eine spezifische Anweisung
        
          Trigger
          Das Ereignis, das den Workflow startet (Push, PR, Schedule usw.)
          Der Startzeitpunkt

Ein Workflow kann mehrere Jobs enthalten, und jeder Job kann mehrere Steps enthalten. Jobs werden standardmäßig parallel ausgeführt, können aber mit Abhängigkeiten für die sequenzielle Ausführung konfiguriert werden.

Struktur eines YAML-Workflows

Jeder Workflow befindet sich im Verzeichnis .github/workflows/ des Repositories. Hier ist die Grundstruktur einer Workflow-Datei:


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

# Trigger: wann der Workflow ausgeführt wird
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

# Globale Umgebungsvariablen
env:
  NODE_VERSION: '20'

# Die auszuführenden Jobs
jobs:
  build:
    # Runner: Virtuelle Maschine zur Ausführung
    runs-on: ubuntu-latest

    # Steps des Jobs
    steps:
      # Step 1: Code auschecken
      - name: Checkout repository
        uses: actions/checkout@v4

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

      # Step 3: Abhängigkeiten installieren
      - name: Install dependencies
        run: npm ci

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

Die Wichtigsten Trigger

Trigger bestimmen, wann ein Workflow gestartet wird. GitHub Actions unterstützt Dutzende von Ereignissen, aber für Frontend-Projekte sind die am häufigsten verwendeten:


on:
  # Bei jedem Push zu den angegebenen Branches
  push:
    branches: [main, develop]
    paths:
      - 'src/**'
      - 'package.json'

  # Bei jeder Pull Request zu main
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened]

  # Geplante Ausführung (Cron)
  schedule:
    - cron: '0 6 * * 1'  # Jeden Montag um 6:00 UTC

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

Vorsicht bei Push-Triggern

Der paths-Filter ist sehr nützlich, um unnötige Builds zu vermeiden: Wenn Sie nur die README ändern, macht es keinen Sinn, die gesamte Pipeline erneut auszuführen. Achten Sie jedoch darauf, keine kritischen Dateien wie angular.json oder tsconfig.json auszuschließen, die den Build beeinflussen.

2. Vollständiger CI-Workflow für Angular

Bauen wir nun einen vollständigen Continuous-Integration-Workflow für ein Angular-Projekt. Dieser Workflow führt nacheinander aus: Abhängigkeiten installieren, Linting, Unit-Tests und Produktions-Build.


# .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

Dieser Workflow definiert drei Jobs in Sequenz dank des Schlüsselworts needs: zuerst Lint, dann Tests, schließlich Build. Wenn Lint fehlschlägt, werden die Tests nicht ausgeführt; wenn die Tests fehlschlagen, startet der Build nicht.

Erweitertes Caching von Abhängigkeiten

Das Schlüsselwort cache: 'npm' in der setup-node-Action bietet ein Basis-Caching. Für eine feinere Kontrolle können wir direkt die actions/cache-Action verwenden:


  - 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

Der Cache-Schlüssel verwendet den Hash der package-lock.json-Datei: Wenn sich die Abhängigkeiten nicht ändern, wird der Cache wiederverwendet und die Installation vollständig übersprungen. Dies kann die Pipeline-Zeit um 30-60 Sekunden pro Ausführung reduzieren.

3. Matrix Strategy: Multi-Versions-Tests

Die Matrix Strategy ermöglicht es, denselben Job mit verschiedenen Parameterkombinationen auszuführen. Für ein Angular-Projekt ist sie besonders nützlich, um auf mehreren Node.js-Versionen zu testen:


  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

Wann die Matrix Strategy Verwenden

Tests auf mehreren Node.js-Versionen (aktuelle und vorherige LTS)
Tests auf mehreren Betriebssystemen (Ubuntu, Windows, macOS)
Build für verschiedene Umgebungen (Staging, Production)
Tests mit verschiedenen Browser-Versionen

4. CD: Automatisches Deployment auf Firebase

Nach dem Bauen und Testen der Anwendung ist der nächste Schritt das automatische Deployment. Sehen wir uns an, wie man das Deployment auf Firebase Hosting konfiguriert, eine der gängigsten Optionen für Angular-Anwendungen.


# .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 für Pull Requests

Eine leistungsfähige Funktion von Firebase Hosting ist die Möglichkeit, automatische Preview Channels für jede Pull Request zu erstellen, die dem Team ermöglichen, Änderungen vor dem Merge zu überprüfen.

Deployment auf Vercel

Für diejenigen, die Vercel als Hosting-Plattform bevorzugen, ist die Konfiguration ebenso einfach. Vercel bietet native Unterstützung für Angular-Projekte.

5. Artifacts: Dateien zwischen Jobs Teilen

Artifacts ermöglichen das Teilen von Dateien zwischen verschiedenen Jobs desselben Workflows. Dies ist grundlegend, um den Build vom Deployment zu trennen, ohne neu zu kompilieren.

      Best Practices für Artifacts
      Setzen Sie immer retention-days, um keinen Speicherplatz zu verschwenden
Verwenden Sie beschreibende Namen für Artifacts (angular-dist, coverage-report)
Laden Sie nur die benötigten Dateien hoch, nicht das gesamte node_modules-Verzeichnis
Für sehr große Dateien ziehen Sie eine Komprimierung vor dem Upload in Betracht

    

6. Branch Protection Rules

Die Branch Protection Rules von GitHub ermöglichen es, Einschränkungen für kritische Branches festzulegen. In Kombination mit CI-Workflows schaffen sie eine automatische Qualitätsbarriere.

Require a pull request before merging: Verhindert direkte Pushes auf main
Require status checks to pass before merging: CI-Workflows müssen bestehen
Require branches to be up to date before merging: Der Branch muss aktuell sein
Require conversation resolution before merging: Alle Kommentare müssen aufgelöst sein

7. Wiederverwendbare Workflows

Bei der Verwaltung mehrerer Repositories mit ähnlichen Konfigurationen vermeiden Reusable Workflows Code-Duplizierung. Ein wiederverwendbarer Workflow wird mit dem Trigger workflow_call definiert.

Vorteile Wiederverwendbarer Workflows

DRY: Ein einziger Wartungspunkt für die CI/CD-Logik
Standardisierung: Alle Repositories folgen denselben Praktiken
Versionierung: Sie können eine bestimmte Version des Workflows referenzieren (@main, @v1)
Sicherheit: Secrets werden explizit übergeben, nicht global geteilt

8. Vollständiges Beispiel: End-to-End-Pipeline

Kombinieren wir alle Konzepte in einer vollständigen Pipeline, die CI und CD mit Branch Protection verwaltet. Die concurrency-Option ist entscheidend: Bei mehreren schnellen Pushes auf denselben Branch wird der vorherige Workflow automatisch abgebrochen.

9. Debugging und Best Practices

Wenn ein Workflow fehlschlägt, kann das Debugging frustrierend sein. Hier sind die effektivsten Strategien:

Debug Logging Aktivieren

ACTIONS_RUNNER_DEBUG = true für detaillierte Runner-Logs
ACTIONS_STEP_DEBUG = true für detaillierte Step-Logs

      Best Practices für GitHub Actions
      Verwenden Sie npm ci statt npm install für deterministische Installationen
Fixieren Sie immer die Versionen der Actions (@v4 statt @main)
Konfigurieren Sie concurrency, um doppelte Builds zu vermeiden
Nutzen Sie den Cache, um die Ausführungszeiten zu reduzieren
Trennen Sie Jobs für schnelles Feedback (Lint schlägt sofort fehl, nicht nach dem Build)
Verwenden Sie environment zum Schutz von Produktions-Secrets
Setzen Sie timeout-minutes, um blockierte Jobs zu vermeiden
Überwachen Sie den Verbrauch der GitHub Actions-Minuten in Ihrem Kontoplan

    

Fazit

In diesem Artikel haben wir eine vollständige CI/CD-Pipeline für eine Angular-Anwendung mit GitHub Actions aufgebaut. Wir haben die grundlegenden Konzepte (Workflow, Job, Step, Trigger) erkundet, das Caching von Abhängigkeiten implementiert, die Matrix Strategy für Multi-Versions-Tests konfiguriert und das automatische Deployment auf Firebase und Vercel eingerichtet.

Der Schlüssel zum Erfolg mit CI/CD-Pipelines ist die progressive Iteration: Beginnen Sie mit einem einfachen Workflow (Lint + Build), fügen Sie dann Tests hinzu und schließlich das automatische Deployment. Versuchen Sie nicht, alles auf einmal zu implementieren.

Im nächsten Artikel der Serie werden wir Docker für Frontend-Entwickler erkunden und lernen, eine Angular-Anwendung mit Multi-Stage Dockerfile zu containerisieren und Entwicklungsumgebungen mit Docker Compose zu verwalten.

Konzept	Beschreibung	Analogie
Workflow	Eine YAML-Datei in `.github/workflows/`, die die gesamte Automatisierung definiert	Das vollständige Rezept
Job	Eine Gruppe von Steps, die auf einem bestimmten Runner ausgeführt wird	Eine Phase des Rezepts
Step	Ein einzelner Befehl oder eine Aktion innerhalb eines Jobs	Eine spezifische Anweisung
Trigger	Das Ereignis, das den Workflow startet (Push, PR, Schedule usw.)	Der Startzeitpunkt