Plesk Git deploy: setup repository e deploy automatico

Plesk e Git: deploy moderno dei siti

Plesk supporta nativamente Git per il deploy delle applicazioni web. Tramite l'estensione Git si possono collegare repository GitHub/GitLab/Bitbucket o creare repository locali sul server, con deploy automatico ad ogni push.

Questa funzionalita' e' particolarmente utile per:

• Workflow CI/CD dove il codice viaggia da repository a produzione
• Tenere traccia delle modifiche fatte sul server
• Rollback rapidi a versioni precedenti
• Collaborazione tra developer

Installare l'estensione Git

Plesk Obsidian include Git nativamente. Se manca:

1. Andare in Extensions → Extensions Catalog
2. Cercare "Git"
3. Cliccare Install

Repository remoto (GitHub/GitLab)

Per collegare un repository esterno:

1. Aprire Subscriptions → dominio.it → Git
2. Cliccare Add Repository
3. Selezionare Remote Git hosting
4. Inserire l'URL del repository (HTTPS o SSH)
5. Specificare il branch (es. main)
6. Scegliere la directory di destinazione (es. httpdocs)

Per repository privati via SSH, copiare la chiave pubblica generata da Plesk nelle Deploy Keys del repository.

Repository locale

In alternativa Plesk puo' ospitare il repository localmente:

1. Selezionare Local repository
2. Plesk crea un repository Git in /var/www/vhosts/dominio.it/git/nome.git
3. Aggiungere il remote sul proprio computer:

   git remote add plesk ssh://user@server.tld/var/www/vhosts/dominio.it/git/sito.git

4. Push per fare deploy:

   git push plesk main

Modalita' di deploy

Plesk offre tre modalita':

• Manual: deploy avviato manualmente dal pannello
• Automatic: deploy automatico ad ogni push (webhook per repo remoti)
• Additional deployment actions: comandi shell eseguiti dopo il pull (es. composer install, npm run build, php artisan migrate)

Configurare il webhook

Per il deploy automatico da GitHub:

1. Plesk mostra l'URL del webhook (es. https://server.tld:8443/modules/git/webhook.php?...)
2. Su GitHub: Settings → Webhooks → Add webhook
3. Payload URL: l'URL fornito da Plesk
4. Content type: application/json
5. Events: Just the push event
6. Salvare

Deployment actions

I post-deploy hooks permettono di automatizzare task tipici. Esempio per un'app Laravel:

composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache

Per un'app Node.js:

npm ci --production
pm2 restart app

Per un sito statico (Hugo/Jekyll):

hugo --minify --destination httpdocs

Branch multipli e staging

Su una sottoscrizione Plesk si possono configurare più' repository (uno per branch):

• Repository main → httpdocs (produzione)
• Repository develop → staging/httpdocs (staging su subdomain)

Crea il subdomain staging.dominio.it e collegalo al branch develop.

Rollback

In caso di errore dopo un deploy:

1. Identificare il commit precedente funzionante
2. Cliccare su Deploy e selezionare il commit specifico
3. Plesk effettua il checkout di quel commit nella directory di destinazione

Log di deploy

Lo storico dei deploy e' visibile nel pannello Git con timestamp, commit hash e output dei deployment actions. Utile per debugging quando un deploy fallisce.

SSH Deploy Keys

Per repository privati GitHub/GitLab via SSH, Plesk genera automaticamente una coppia di chiavi SSH per la sottoscrizione. La chiave pubblica si trova in ~/.ssh/id_rsa.pub dell'utente di sistema. Per GitHub:

1. Aprire il repository → Settings → Deploy keys
2. Add deploy key
3. Incollare la chiave pubblica
4. NON spuntare "Allow write access" (deploy keys read-only sono sicuri)

Token-based authentication

In alternativa alle SSH keys, GitHub supporta Personal Access Token (PAT) per HTTPS. Plesk supporta entrambi i metodi. Per repository pubblici nessuna credenziale e' necessaria.

Submodules

Se il repository usa Git submodules, abilitare Initialize submodules on deploy. Plesk eseguira' automaticamente git submodule update --init --recursive dopo il pull.

Hook server-side

Per validazioni custom prima del deploy (es. testare che la build funzioni), si possono usare i Git hooks server-side. Esempio pre-receive che blocca push diretti su main:

#!/bin/bash
while read oldrev newrev refname; do
    if [[ "$refname" == "refs/heads/main" ]]; then
        echo "Push diretto su main vietato"
        exit 1
    fi
done

Multi-deploy environments

Pattern comune: repository unico con più' branch (main, staging, develop) deployati su domini diversi. Plesk permette di configurare repository separati per ogni branch sulla stessa sottoscrizione.

Sicurezza .git

La directory .git/ non deve essere accessibile via HTTP: contiene cronologia, credenziali nei file di config, codice sorgente. Plesk per default protegge le directory .git. Verificare con:

curl -I https://dominio.it/.git/config

Dovrebbe rispondere 403 Forbidden.

Workflow CI/CD con GitHub Actions

Per workflow più' avanzati di un semplice push-to-deploy, GitHub Actions puo' triggerare il deploy Plesk via webhook o SSH dopo aver eseguito test/build:

name: Deploy Plesk
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: composer install
      - run: vendor/bin/phpunit
  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - run: curl -X POST $PLESK_WEBHOOK_URL

Repository monorepo

Plesk Git supporta repository monorepo dove un solo repo contiene più' progetti. Configurare il deploy con path più' specifico (es. apps/frontend) tramite l'opzione Repository folder.

Push to deploy vs pull

Le due strategie principali:

• Pull: Plesk fa clone+pull del remoto. Funziona con repo remoti su GitHub/GitLab.
• Push: Plesk e' il remoto e riceve push diretti. Funziona per repo locali.

La pull e' più' robusta per workflow multi-developer (la fonte di verita' resta su GitHub).

Hai bisogno di aiuto?

Se vuoi gestione Plesk dal team di G Tech Group, scrivici tramite il modulo di contatto.