La distribuzione continua è una parte essenziale dello sviluppo web moderno. Consente agli sviluppatori di distribuire automaticamente le modifiche da un sistema di controllo di versione a un ambiente live. Questo approccio riduce gli errori manuali e velocizza il processo di sviluppo, assicurando che il vostro sito web sia sempre aggiornato con le ultime modifiche al codice.
Come utenti di Kinsta, potete utilizzare l’SSH per inviare le modifiche direttamente al vostro server. Con GitHub Actions potete automatizzare l’intero processo di deploy, distribuendo senza problemi gli aggiornamenti al vostro sito live.
Questo articolo spiega come impostare la distribuzione continua per il vostro sito WordPress ospitato su Kinsta utilizzando le GitHub Actions. Ci occupiamo di tutto, dall’impostazione dell’ambiente locale all’invio delle modifiche a GitHub e alla distribuzione automatica al vostro sito live.
Prerequisiti
Prima di poter impostare la distribuzione continua del vostro sito WordPress su Kinsta, sono necessarie alcune cose:
- Il sito WordPress deve essere già ospitato su Kinsta.
- Dovrete eseguire il pull del vostro sito in locale. Potete utilizzare DevKinsta o scaricare un backup.
- Avrete bisogno di un repository GitHub per archiviare ed eseguire il push del codice del sito.
- Conoscenze di base di Git, come il push del codice e l’utilizzo di un file
.gitignore
.
Estrarre il sito in locale e configurare GitHub
Come utenti di Kinsta, il modo più semplice per accedere ai file locali del vostro sito WordPress è usare DevKinsta. Con pochi clic, potete trasferire il vostro sito dal server Kinsta a DevKinsta, avendo così la possibilità di lavorare sul vostro sito in locale.
Per farlo:
- Aprite DevKinsta e cliccate su Aggiungi sito.
- Selezionate l’opzione Importa da Kinsta. In questo modo scaricherete tutto ciò che riguarda il sito in modo da potervi accedere localmente per lo sviluppo.
Una volta che il sito sarà disponibile in locale, aprite la cartella del sito nel vostro editor di codice preferito. Prima di inviare i file a GitHub, aggiungete un file .gitignore
nella directory principale del vostro progetto per evitare di caricare file core di WordPress non necessari, upload o informazioni sensibili. Potete utilizzare un template standard di .gitignore
per WordPress. Copiate il contenuto del template e salvatelo.
Successivamente, create un repository GitHub e inviate i file del vostro sito a GitHub.
Impostazione dei segreti di GitHub per Kinsta
Per automatizzare il deployment da GitHub a Kinsta, vi serviranno alcuni importanti dati SSH, tra cui il nome utente, la password, la porta e l’indirizzo IP. Poiché si tratta di dati sensibili, memorizzateli come segreti GitHub.
Per aggiungere i segreti in GitHub:
- Andate al vostro repository su GitHub.
- Cliccate su Settings > Secrets and Variables > Actions > New repository secret.
- Aggiungete i seguenti segreti:
KINSTA_SERVER_IP
KINSTA_USERNAME
PASSWORD
PORT
Potete trovare questi dettagli nella pagina Info del vostro sito nella vostra dashboard MyKinsta.
Una volta completata questa configurazione, potete configurare la distribuzione automatica per il vostro sito WordPress.
Configurazione del server Kinsta
Prima di automatizzare il processo di distribuzione con GitHub Actions, dovete configurare il vostro server Kinsta per ricevere e distribuire il codice dal vostro repository GitHub.
Questo comporta due passaggi: la creazione di un repository Git bare sul vostro server Kinsta e l’impostazione di un hook post-receive
per distribuire automaticamente le ultime modifiche al vostro sito live.
1. Creare un repository Git bare su Kinsta
Un repository Git bare è una destinazione remota dove GitHub invierà il vostro codice. Questo repository non ha una directory di lavoro: è un repository centrale progettato per ricevere e archiviare il vostro codice.
Per farlo, accedete al vostro server Kinsta tramite SSH utilizzando il comando terminale SSH disponibile nella dashboard MyKinsta:
Quindi, navigate nella cartella privata del vostro server (o createla se non esiste già):
mkdir -p /www/your-site/private
cd /www/your-site/private
Qui, sostituite your-site
con il nome effettivo della cartella del vostro sito, che potete trovare nel percorso della dashboard.
Infine, create il repository Git bare:
git init --bare your-repo.git
Per your-repo
, potete utilizzare il nome del vostro repository GitHub per coerenza, ma potete chiamarlo come preferite.
Questo repository riceverà il codice inviato da GitHub.
2. Configurare l’hook post-receive
Quando il vostro repository Git bare sarà pronto, dovrete impostare un hook post-receive
. Questo script distribuirà automaticamente il codice al vostro sito live ogni volta che verranno apportate nuove modifiche al branch main
di GitHub.
Per farlo, andate alla cartella hooks del vostro repository Git bare:
cd /www/your-site/private/your-repo.git/hooks
Create e modificate l’hook post-receive
:
nano post-receive
Successivamente, aggiungete il seguente script al file post-receive
. Questo script controllerà il codice più recente nella directory public
del vostro sito live:
#!/bin/bash
TARGET="/www/your-site/public"
GIT_DIR="/www/your-site/private/your-repo.git"
while read oldrev newrev ref
do
BRANCH=$(git rev-parse --symbolic --abbrev-ref $ref)
if [[ $BRANCH == "main" ]];
then
echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
else
echo "Ref $ref received. Doing nothing: only the main branch may be deployed on this server."
fi
done
Lo script precedente distribuisce il codice solo dal branch main
. La variabile TARGET
punta alla directory in cui si trovano i file del vostro sito live (/www/your-site/public
). La variabile GIT_DIR
punta al repository Git bare.
Salvate e uscite dal file premendo Ctrl + X, poi Y e Invio.
Infine, rendete lo script eseguibile in modo che possa essere eseguito automaticamente dopo ogni push:
chmod +x post-receive
A questo punto, l’hook di post-receive
è pronto per distribuire automaticamente il codice ogni volta che vengono apportate modifiche al branch main
del vostro repository GitHub.
3. Generare e aggiungere un token di accesso personale (PAT) a GitHub
Poiché GitHub non supporta più l’autenticazione basata su password, è necessario utilizzare un PAT per autenticarvi quando inviate codice a GitHub tramite SSH. Questo token permetterà a GitHub di accettare i vostri push in modo sicuro.
Per generare il token:
- Accedete al vostro account GitHub e cliccate sulla foto del vostro profilo, quindi selezionate Settings.
- Nella barra laterale di sinistra, cliccate su Developer settings.
- Cliccate su Personal access tokens > Tokens (classic).
- Cliccate su Generate new token e dategli un nome (ad esempio, “Kinsta Deployment Token”).
- In Select scopes, selezionate
repo
(per avere il pieno controllo dei repository privati). - Cliccate su Generate token e copiate il token. (Non potrete più vederlo)
Quindi, eseguite il seguente comando per aggiungere il vostro repository GitHub come remoto, sostituendo i segnaposto con i vostri dati reali:
git remote add origin https://your-username:[email protected]/your-username/your-repo.git
Sostituite:
your-username
con il vostro nome utente GitHub.YOUR_PERSONAL_ACCESS_TOKEN
con il token appena generato.your-repo
con il nome del vostro repository GitHub.
Creare il workflow delle GitHub Actions per il deploy automatico
Ora che il vostro sito WordPress è sul vostro computer locale, è stato inviato a GitHub e avete configurato i segreti GitHub necessari, è il momento di creare un workflow GitHub Actions. Questo workflow distribuisce automaticamente le modifiche a Kinsta ogni volta che eseguite il push sul branch main
.
Per automatizzare la distribuzione, dovrete creare un file YAML che definisca come avverrà la distribuzione. Ecco come configurarlo:
- Create una nuova directory chiamata
.github/workflows
nel vostro repository GitHub. - All’interno di questa directory, create un nuovo file chiamato
deploy.yml
. - Aggiungete il seguente contenuto al file
deploy.yml
:
name: Deploy to Kinsta
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Deploy to Kinsta via SSH
uses: appleboy/[email protected]
with:
host: ${{ secrets.KINSTA_SERVER_IP }}
username: ${{ secrets.KINSTA_USERNAME }}
password: ${{ secrets.PASSWORD }}
port: ${{ secrets.PORT }}
script: |
cd /www/your-site/private/your-repo.git # Navigate to the bare Git repository on Kinsta
git --work-tree=/www/your-site/public --git-dir=/www/your-site/private/your-repo.git fetch origin main # Fetch the latest changes from GitHub
git --work-tree=/www/your-site/public --git-dir=/www/your-site/private/your-repo.git reset --hard origin/main # Deploy changes to the live site
Uno sguardo più approfondito a questo workflow
Ecco la ripartizione del workflow:
- Trigger: il workflow viene attivato ogni volta che il codice viene spinto nel branch
main
del vostro repository GitHub. - Job: il workflow contiene un
job
chiamatodeploy
, che viene eseguito su una macchina virtuale Ubuntu (ubuntu-latest
). - Checkout code: questo passaggio utilizza l’azione
actions/checkout@v2
per prelevare il codice più recente dal vostro repository GitHub. - Deploy via SSH:
appleboy/ssh-action
viene utilizzato per connettersi in modo sicuro al vostro server Kinsta tramite SSH utilizzando i segreti che avete configurato (IP del server, nome utente, password e porta). Lo script in questo passaggio esegue i seguenti comandi:cd /www/your-site/private/your-repo.git
: naviga nel repository Git sul vostro server Kinsta.git fetch origin main
: recupera le ultime modifiche dal branchmain
nel vostro repository GitHub.git reset --hard origin/main
: applica le modifiche aggiornando il sito live nella directorypublic
dove è ospitato WordPress.
Testare il workflow
Una volta impostato il workflow, potete testarlo apportando una piccola modifica al branch main
del vostro repository GitHub. Ogni volta che apportate una modifica, GitHub Actions attiva automaticamente la distribuzione, prelevando l’ultima versione del vostro codice e distribuendola al vostro sito live su Kinsta.
Potete monitorare lo stato della distribuzione accedendo alla scheda Actions del vostro repository GitHub. Se il workflow incontra degli errori, vedrete dei log dettagliati che vi aiuteranno a risolvere i problemi.
Riepilogo
Impostando la distribuzione continua per il vostro sito WordPress utilizzando le GitHub Actions, automatizzate il vostro workflow di sviluppo, assicurandovi che ogni modifica apportata a GitHub venga automaticamente distribuita al vostro sito live su Kinsta.
Inoltre, permette di integrare ulteriori flussi di lavoro nella pipeline, come i test e la formattazione utilizzando il pacchetto @wordpress/scripts.
Cosa ne pensate di questo processo? C’è qualcos’altro che vorreste vi spiegassimo o avete riscontrato qualche errore nel seguire questa guida? Condividete domande e commenti nella sezione dei commenti qui sotto!
Lascia un commento