Come abbiamo visto in un precedente articolo, il pannello di Plesk messo a disposizione da RocketWeb Hosting supporta Git, il sistema di controllo versione del codice (“version control system”, VCS) più utilizzato al mondo.
I vantaggi dell’uso di Git sono molteplici:

• Diverse versioni dello stesso file
• Ripristino di una versione precedente a quella attuale di un file
• Storico delle modifiche con data, autore, note, etc..
• Collaborazione tra più persone sullo stesso progetto
• Sistema di branch che permette di creare un flusso di lavoro alternativo

Git trova il suo spazio d’impiego naturale in ambito di sviluppo software e Web, inclusi i siti, e Plesk, la piattaforma di gestione Web scelta anche da RocketWeb Hosting, offre appunto l’integrazione con Git. Vediamo dunque di analizzare in dettagli i concetti di Repository, di Commit e di Branch per sviluppare con Git un sito Web ospitato su piattaforma Plesk.

Repository, locale e remoto

Nell’articolo Git, Plesk e RocketWeb Hosting abbiamo spiegato che cos’è un repository (repo), ovvero quello spazio che include tutti i file gestiti da Git e viene creato quando si comincia un nuovo progetto.
Un repository può essere locale: è sufficiente accedere al proprio account di Web Hosting Plesk e selezionare l’icona Git.

• Quindi selezioniamo Local repository;
• Impostiamo il nome del repo (di default è nome-sito.git), la cartella dello spazio web (di default /httpdocs/) dove verrà aggiunto;
• Impostiamo l’indirizzo a cui è raggiungiungibile il sito (ad es. se si specifica il percorso /httpdocs/test-git e il sito è esempio.it, il contenuto del repo sarà raggiungibile a esempio.it/test-git):
• Scegliamo il Deployment Mode, cioè la modalità di pubblicazione: Automatic -i file vengono pubblicati appena si esegue il push del commit sul repo-, Manual -la pubblicazione dei file è manuale, ovviamente previo push del commit-, oppure No deployment - i file non vengono pubblicati.

Inoltre, Plesk permette di specificare delle azioni aggiuntive da eseguire automaticamente dopo il deployment, spuntando l’opzione Enable additional deploy actions: qui vanno inseriti i comandi -uno per riga- che si darebbero da linea di comando, con l’accortezza che se SSH non è disponibile, allora i comandi vengono eseguiti in un ambiente chrooted e non è possibile eseguire file al di fuori dell’ambiente stesso, che è limitato a ./httpdocs e sottocartelle. In alcuni casi questa opzione è ben gradita, come quando non basta pubblicare i file ma servono, ad esempio, determinate operazioni sul database.
Una volta aggiunto il repo locale, questo sarà mostrato nella dashboard Plesk del sito, e clickando sul suo nome possiamo accedere alla pagina di gestione del repo: possiamo scegliere la branch da utilizzare e il percorso sul sito del  repo con Change branch and path, modificare le impostazioni riguardo nome, modo di pubblicazione (automatico, manuale, no pubblicazione) e comandi aggiuntivi come visto in fase di creazione del repository, e un’utile pagina di aiuto con i comandi base per creare in locale un repo ed eseguire il push sul proprio spazio web hosting: questi sono gi relativi al proprio repo, non sono comandi generici, quindi basta un copia&incolla sul proprio computer in Git.
Infine, possiamo rimuovere un repository con il pulsante Remove repository; non vengono cancellati i file pubblicati, e il repo può essere riaggiunto in un secondo momento.

A questo punto il repository è correttamente aggiunto ed impostato su Plesk, quindi si può lavorare con il proprio computer (=in locale) sul sito, eseguire il commit del lavoro ed il push.
Se il metodo di pubblicazione è impostato su automatico, non appena Git ha terminato di caricare i file, questi verranno pubblicati su Internet; se invece il metodo è impostato su manuale, occorre premere l’apposito pulsante situato nella pagina di amministrazione Plesk del sito. Naturalmente il metodo di pubblicazione può essere cambiato tra le impostazioni del repo.

Uno dei punti di forza di Git è il suo sistema di branch, un concetto che abbiamo già visto nel precedente articolo e che naturalmente è supportato da Plesk. Di default la branch master è attiva, e si può avere una sola branch attiva in un dato momento. Per prima cosa creiamo la branch nel repo locale con il comando git checkout -b branch-1, quindi eseguiamo commit con git commit –m "creazione branch" e push dei file con git push –u origin branch-1 . La branch è ora disponibile su Plesk, e in Change branch and path la si seleziona nel menu a tendina.

L’uso di un repo remoto presenta alcune differenze rispetto al repo locale, ma la sostanza rimane la stessa. Il repo va creato, a scelta, con BitBucket o GitHub, e poi clonato in Plesk tramite l’apposito wizard di configurazione: questa volta scegliamo Remote Git hosting anziché Local repository. Si può inserire l’indirizzo del repo in formato HTTP/HTTPS o SSH (informazioni in Github e Bitbucket su come aggiungere le chiavi SSH), quest’ultimo caso è obbligatorio se si usa un repo privato.

Anche in questo caso va specificato il percorso di pubblicazione e il Deployment Mode. Plesk eseguirà la clonazione del repo che al termine delle operazioni sarà sincronizzato con quello remoto.


Al termine delle operazioni il repo su Plesk creato sarà un clone del repo remoto da cui scaricare il nuovo contenuto e pubblicarlo - ovviamente in base al metodo (manuale o automatico) selezionato. Questa visuale può essere raggiunta anche dalla dashboard di amministrazione Plesk e contiene tutti i comandi disponibili per il repo.
Analogamente con il repo locale, le informazioni sui commit sono disponibili in Commit Logs, il percorso di pubblicazione e la branch su cui lavorare si scelgono in Change branch and path.
Le impostazioni del repo sono in Repository Settings, e mostrano alcune differenze rispetto a quelle del repo locale.

Accanto al nome del repo, metodo di pubblicazione ed azioni addizionali (che hanno le stesse limitazioni come nel caso del repo locale), troviamo Git repository -l’indirizzo web del repo-, SSH public key -la chiave SSH per connettersi al repo remoto e va aggiunta in Github o Bitbucket-, e Webhook URL.

Un webhook non è altro che un particolare URL da inserire nel repo remoto (in Github o Bitbucket) e che viene associato a particolari eventi che, quando si verificano, determinano il verificarsi di altre azioni invocate appositamente. Ad esempio si può impostare un trigger di eventi che esegue su Plesk il pull dei dati non appena avviene il push dei dati sul repo remoto; non ci fosse questo trigger, bisognerebbe eseguire manualmente il pull dei dati in Plesk. Se poi si è impostato il metodo di pubblicazione automatico, non appena si esegue il push del commit su repo remoto, i file vengono pubblicati.

Maggiori informazioni su come configurare un webhook che esegue un pull automatico in Github e Bitbucket si trovano, rispettivamente, a questo e quest’altro indirizzo.

La pubblicazione manuale del repo avviene tramite apposito pulsante Deploy, non dopo aver scaricato le modifiche con Pull Updates.

Le informazioni sui commit sono disponibili tramite apposito link Commit Logs, che contengono data, hash identificativo, nome utente e messaggio del commit. Sono presenti dei filtri che permettono di impostare una ricerca specifica per parametri.

Flusso di lavoro e ambiente di staging

Abbiamo visto come creare un repo locale o remoto e gestirlo, vediamo ora un flusso di lavoro per la gestione del proprio sito con Git.

• Si lavora sul sito con le modifiche in locale.
• Si aggiungono manualmente con il comando git add (da terminale) i file su cui eseguire il commit all’area di stage.
• Si controlla lo stato dei file con git status per trovare cosa è stato cambiato, quando, come e perché (e da chi, se l’ambiente di sviluppo coinvolge più persone) e si verifica che sia tutto come ci si aspetta.
• Si esegue il commit dei file al repo locale con git commit -m “messaggio commit”. Le modifiche sono salvate solo sul computer locale.
• Si esegue il push del repo locale sul repo locale su Plesk o remoto su Gituhub/Bitbucket.
• Se si è selezionato il deployment automatico, non bisogna fare nulla: i file vengono pubblicati non appena si esegue il push. Se si usa un repo remoto, va impostato l’apposito webhook per il pull automatico; in alternativa, bisogna procedere al pull delle modifiche tramite l’apposito tasto Pull Updates nella dashboard di amministrazione Plesk.
  Se invece si è scelto il deployment manuale, va selezionato il tasto specifico Deploy.

Infine, abbiamo parlato della possibilità di usare Git per creare un ambiente di staging facile da gestire: per farlo va creata una branch con il comando git checkout -b nome-branch sul computer dal quale si lavora sul sito, poi si procede all’aggiunta dei file (git add) e del commit (git commit -m “messaggio commit”). Quindi si esegue il push dei dati.
In Plesk si sceglie la branch su cui lavorare e la si imposta in un percorso specifico, ad esempio /staging-area/, accessibile solo tramite autenticazione (guida RocketWeb) ed esclusa dall’indicizzazione dei bot dei motori di ricerca tramite file robots.txt (guida RocketWeb). Quindi si esegue il pull dei dati tramite tasto Pull Updates e si lavora normalmente sulla nuova branch, magari chiamata dev. Quando si verifica che il sito presente in questa branch è pronto per la messa in produzione, basta cambiare il percorso di pubblicazione selezionando la root del sito (o il percorso adatto).