{"id":72482,"date":"2023-08-21T14:10:34","date_gmt":"2023-08-21T13:10:34","guid":{"rendered":"https:\/\/kinsta.com\/it\/?p=72482&preview=true&preview_id=72482"},"modified":"2023-11-03T10:03:44","modified_gmt":"2023-11-03T09:03:44","slug":"come-creare-una-pipeline-ci-cd","status":"publish","type":"post","link":"https:\/\/kinsta.com\/it\/blog\/come-creare-una-pipeline-ci-cd\/","title":{"rendered":"Come creare una pipeline CI\/CD con GitHub Actions e l’API di Kinsta"},"content":{"rendered":"

Nel frenetico mondo dello sviluppo web<\/a>, integrazione continua e distribuzione continua (CI\/CD<\/a>) sono diventate prassi indispensabili per fornire software di alta qualit\u00e0 in modo efficiente. Il CI\/CD permette agli sviluppatori di automatizzare il processo di creazione, test e distribuzione delle modifiche al codice, riducendo il rischio di errori umani e favorendo iterazioni pi\u00f9 rapide.<\/p>\n

Questo articolo spiega l’importanza del CI\/CD, come creare una pipeline CI e come impostare in modo programmatico la distribuzione continua nella propria pipeline CI con l’API di Kinsta<\/a>, il tutto usando GitHub Actions nel proprio repository GitHub<\/a>.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Perch\u00e9 usare il CI\/CD?<\/h2>\n

La piattaforma di Hosting di Applicazioni<\/a> di Kinsta ha sempre reso disponibile un’opzione per il deployment automatico che si attiva ogni volta che viene apportata una modifica a un branch specifico del repository Git ospitato. Tuttavia, questo potrebbe non essere l’ideale per progetti di grandi dimensioni con pi\u00f9 membri all’interno del team. Molti sviluppatori<\/a> tendono a non abilitare la distribuzione automatica per diversi motivi.<\/p>\n

Uno di questi \u00e8 che, in un ambiente collaborativo con pi\u00f9 sviluppatori sullo stesso progetto, le distribuzioni automatiche attivate dalla modifica di uno sviluppatore al repository possono generare instabilit\u00e0 e altri problemi non sempre prevedibili. Senza una verifica e una convalida adeguate, anche una piccola modifica al codice potrebbe disturbare il sito live, generando possibili interruzioni e portando ad esperienze negative per gli utenti.<\/p>\n

\u00c8 qui che entra in gioco una pipeline CI\/CD. Creando un workflow CI\/CD accuratamente orchestrato, gli sviluppatori possono assicurarsi che le modifiche al codice vengano sottoposte a test e convalida prima di essere distribuite al sito live. Esistono molti strumenti per implementare il CI\/CD nello sviluppo del software; in questo tutorial utilizzeremo GitHub Actions<\/a>.<\/p>\n

Cos’\u00e8 GitHub Actions?<\/h2>\n

GitHub Actions \u00e8 un potente strumento di automazione fornito da GitHub. Offre agli sviluppatori la possibilit\u00e0 di automatizzare attivit\u00e0, processi e flussi di lavoro nei progetti di sviluppo software. Si integra con i repository di GitHub, cosa che lo rende facile da usare.<\/p>\n

Con GitHub Actions e l’API di Kinsta<\/a>, \u00e8 possibile definire flussi di lavoro personalizzati che si adattano alle esigenze di ogni progetto. Si pu\u00f2 impostare una pipeline CI che testa l’applicazione e attiva il deployment su Kinsta.<\/p>\n

Primi passi con GitHub Actions<\/h2>\n

GitHub Actions si basa sul concetto di workflow, ovvero un insieme di attivit\u00e0 automatizzate che vengono attivate da eventi specifici o programmate a intervalli regolari. Questi eventi possono includere push di codice, richieste di pull, creazione di issue<\/em> e altro ancora. Quando si verifica uno di questi eventi, GitHub Actions esegue automaticamente un workflow associato, eseguendo una serie di passaggi predefiniti.<\/p>\n

Ogni fase del workflow rappresenta un’azione particolare, come la creazione del codice, l’esecuzione di test, il deploy o l’invio di notifiche. Adesso creeremo un workflow con tre attivit\u00e0:<\/p>\n

    \n
  1. Controllare la sintassi con ESLint<\/li>\n
  2. Eseguire i test<\/li>\n
  3. Re-distribuire l’applicazione<\/li>\n<\/ol>\n

    Fase 1: Configurare il repository GitHub<\/h3>\n

    Per iniziare, abbiamo bisogno di un repository GitHub.<\/p>\n

    Qui utilizziamo questo repository GitHub<\/a>, sviluppato per il tutorial Come costruire e distribuire un’applicazione clone di ChatGPT con React e l’API di OpenAI<\/a>.<\/p>\n

    Potete utilizzare lo stesso repository andando su GitHub e selezionando: Use this template<\/strong> > Create new repository<\/strong>.<\/p>\n

    In questa applicazione React, sono stati creati dei test unitari per verificare ogni componente. Viene utilizzato anche ESLint per avere sintassi e formattazione del codice perfette. Se una richiesta di pull o il codice aggiunto tramite merge inviato al repository non supera i test del workflow, la pipeline CI bloccher\u00e0 il deployment.<\/p>\n

    Fase 2: Creare un file del workflow<\/h3>\n

    Definiamo il workflow creando un file YAML nella directory .github\/workflows<\/strong> del repository. Questa directory dovrebbe trovarsi al livello principale del repository. La convenzione di denominazione dei file del workflow \u00e8 nome-del-workflow.yml<\/strong>.<\/p>\n

      \n
    1. Nel repository, creiamo una directory .github<\/strong>.<\/li>\n
    2. All’interno della directory .github<\/strong>, creiamo una nuova directory chiamata workflows<\/strong>.<\/li>\n
    3. All’interno della directory workflows, creiamo un nuovo file con un nome come build-test-deploy.yml<\/strong>.<\/li>\n<\/ol>\n

      Fase 3: Scrivere il workflow CI\/CD<\/h3>\n

      Ora che abbiamo creato il file, definiamo un workflow con i passaggi necessari per verificare la sintassi con ESLint, eseguire i test e distribuire l’applicazione.<\/p>\n

      Creare un evento CI<\/h4>\n

      Quando si crea una pipeline CI, il primo passo \u00e8 dare un nome al workflow e poi impostare l’evento che lo innesca. In questo esempio, i due eventi sono una richiesta di pull e un push al branch principale.<\/p>\n

      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"<\/code><\/pre>\n
      Se si desidera programmare job periodici (CRON job) per attivit\u00e0 specifiche, \u00e8 sufficiente aggiungerli al workflow. Ad esempio, si potrebbero eseguire alcune attivit\u00e0 come il backup del database, la pulizia dei dati o altre attivit\u00e0 di manutenzione periodica.<\/p>\n
      Ecco un esempio di come aggiungere un CRON job al workflow:<\/p>\n
      on:\n  # Existing event triggers for push and pull_request\n\n  # Add a schedule for CRON jobs\n  schedule:\n    - cron: \"0 0 * * *\"<\/code><\/pre>\n
      L’esempio precedente attiver\u00e0 il workflow ogni giorno a mezzanotte (ora UTC) perch\u00e9 la pianificazione cron \u00e8 impostata su 0 0 * * *<\/code>. Si pu\u00f2 personalizzare la pianificazione del cron per esigenze specifiche.<\/p>\n
      Per fare un altro esempio, supponiamo di voler programmare il workflow CI\/CD in modo che venga eseguito ogni luned\u00ec alle 8. Possiamo impostare un CRON job utilizzando l’evento schedule<\/code>:<\/p>\n
      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"\n\n  # Schedule the workflow to run every Monday at 8 a.m. (UTC time)\n  schedule:\n    - cron: \"0 8 * * 1\"\n\njobs:\n # Add jobs<\/code><\/pre>\n
      La sintassi utilizzata nell’evento schedule<\/code> per pianificare i flussi di lavoro di GitHub Actions si basa sulla sintassi cron di UNIX. Permette di definire tempi o intervalli specifici per l’esecuzione automatica del workflow. La sintassi \u00e8 composta da cinque campi che rappresentano diversi aspetti della pianificazione. Ogni campo \u00e8 separato da uno spazio. Il formato generale \u00e8 il seguente:<\/p>\n
      * * * * *\n\u252c \u252c \u252c \u252c \u252c\n\u2502 \u2502 \u2502 \u2502 \u2502\n\u2502 \u2502 \u2502 \u2502 \u2514\u2500 Day of the week (0 - 7) (Sunday to Saturday, where both 0 and 7 represent Sunday)\n\u2502 \u2502 \u2502 \u2514\u2500\u2500\u2500 Month (1 - 12)\n\u2502 \u2502 \u2514\u2500\u2500\u2500\u2500\u2500 Day of the month (1 - 31)\n\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Hour (0 - 23)\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Minute (0 - 59)<\/code><\/pre>\n
      Analizziamo i singoli campi:<\/p>\n