Distribuzione su Live e staging con Deploybot

Se sei stato nello sviluppo web per un po', probabilmente hai sbagliato a trasferire un file mentre stai cercando di aggiornare un sito. Nella migliore delle ipotesi, aggiungi un gruppo di file facilmente identificabili a una directory e li rimuovi per correggere l'errore. Sì, ti costa tempo ed è fastidioso, ma nessun danno.

Nel peggiore dei casi, trasferisci un gruppo di file di temi in modo improprio. Quindi devi capire quali sono stati sovrascritti, quali non appartengono affatto e come diavolo recupererai il corretto stato di funzionamento del tuo tema.

Oggi affronteremo la risoluzione di questo problema utilizzando Git e Deploybot per automatizzare il processo di distribuzione.

Che cos'è la distribuzione automatizzata?

Una distribuzione automatizzata di base ha quattro parti, come mostrato in questo diagramma.

La maggior parte degli sviluppatori inizia solo con il proprio codice e il server. Apportano modifiche alla loro copia di lavoro del sito, quindi inviano tali modifiche direttamente al server tramite FTP. Strumenti come Coda o Dreamweaver hanno un'integrazione FTP diretta in modo che tu possa farlo dall'interno del tuo ambiente di codifica.

Il passaggio successivo che molti sviluppatori fanno è aggiungere un sito di staging in modo che non modifichino direttamente il server live. Puoi farlo con qualcosa come VVV o MAMP. Spesso questo significa anche che stai utilizzando un sistema di controllo della versione come Git per gestire le modifiche apportate al tuo sito di lavoro locale.

Quando aggiungi un sito di staging, aggiungi anche complessità. Come si ottengono le modifiche al codice dal sito di lavoro locale a un sito di staging in cui il cliente può visualizzare le modifiche? Sì, come ho già detto, puoi utilizzare un client FTP di base come FileZilla, Transmit o Forklift per spostare i file mentre apporti modifiche, ma questo è soggetto a errori ed è qui che automatizzare il processo di distribuzione ti farà risparmiare così tanto tempo.

Invece di prendere i file che modifichi e inviarli al tuo server di staging, usi un altro sistema per rilevare automaticamente le modifiche nel tuo repository Git e inviare solo quelle modifiche al sito di staging che il tuo client può utilizzare per controllare il lavoro.

Ciò lascia comunque il tuo sito live come una distribuzione manuale, il che è molto più spaventoso perché può significare la perdita di denaro reale se interrompi un sito di lavoro live. Si supponga invece di impostare il sistema di distribuzione in modo che venga distribuito automaticamente allo staging, quindi il sistema verrà distribuito con un solo clic nell'ambiente live quando sei pronto per l'uso.

Quindi ora hai un sistema simile a questo.

Immergiamoci così posso mostrarti come ho impostato questo processo di distribuzione per ogni client con cui lavoro. Questi sono i passi che faccio appena inizio un nuovo progetto. Mi assicuro sempre che il mio processo di distribuzione sia impostato e funzionante prima di iniziare a svolgere qualsiasi altro lavoro su un progetto client.

Come strutturare il tuo repository Git

La tua prima scelta da fare è, in quale directory imposterai la tua distribuzione automatizzata? A meno che il mio cliente non richieda specificamente il controllo completo del codice sorgente per l'installazione di WordPress, utilizzo la directory wp-content per configurare il mio sistema di distribuzione automatizzata. Ciò inizia nel terminale emettendo questo comando che inizializza un repository git.

git init

Ora è il momento di ignorare i file che non vorrai distribuire tutto il tempo. Si tratta di file come file di backup, immagini e qualsiasi file di progetto personalizzato che molti editor di codice aggiungono a una directory. Puoi vedere il mio solito file .gitignore di seguito.

config/app_config.yml

config/database.yml

config/*.sphinx.conf

config/s3_credentials.yml

*~

*.cache

*.tronco d'albero

*.pid

tmp/**/*

.DS_Store

db/cstore/**

db/sfinge/**

doc/api

documento/app

doc/plugin

doc/*.dot

copertura/*

db/*.sqlite3

*.tmproj

*.sw?

*.esproj

_Appunti*

dwsync.xml

podcast.xml

*.kpf

*caricamenti/*

*.swp

*.idea

*.progetto-sublime

*.spazio di lavoro sublime

*/moduli_nodo/*

tag

*.bak

cache/*

gestisci/*

mu-plugin/*

dp.php

corrente ascensionale/*

le lingue/*

db.php

plugins/wp-rocket/cache.json

Sentiti libero di aggiungere o rimuovere da questo secondo necessità. Quasi tutti i progetti su cui lavoro richiedono una sorta di voce personalizzata per ignorare alcuni file specifici del mio sito di lavoro locale per i quali i siti di staging e live avranno il proprio file personalizzato che non voglio sovrascrivere.

Da qui è il momento di configurare le filiali di cui avrai bisogno per far funzionare il tuo sistema di distribuzione. Uso due rami principali. Il primo è il ramo principale che corrisponde al mio sito di produzione live. In secondo luogo, è un ramo che etichetto come staging e corrisponde al sito di staging che voglio che il mio cliente utilizzi per controllare le modifiche che stiamo apportando.

Quando hai inizializzato il tuo repository Git hai già il tuo ramo principale, quindi usa questo comando per aggiungere un ramo di staging e controllalo.

git checkout -b staging

Questo comando crea ed estrae un nuovo ramo. Se non conosci git, puoi trovare maggiori informazioni sui comandi disponibili nella documentazione di Git.

Ora dovrai inserire il tuo progetto nel tuo sistema di controllo del codice sorgente. Github e Bitbucket sono due scelte popolari che funzionano entrambe con il sistema di distribuzione automatizzato che useremo chiamato Deploybot. Quando crei un nuovo repository con uno dei due siti, ti daranno ulteriori indicazioni per aggiungere il tuo repository locale alla tua versione online in Github o Bitbucket.

• Documentazione di configurazione del repository Bitbucket
• Documentazione di configurazione del repository Github

Configurazione di Deploybot

Quando mi sono occupato per la prima volta di lavori più complessi come sviluppatore, il mio amico Duane ha continuato a consigliarmi Deploybot quando mi sono lamentato online per aver rovinato la distribuzione FTP manuale. Ci sono voluti una serie di raccomandazioni prima che finalmente facessi ciò che mi è stato detto, ma ora sono un cliente felice di Deploybot da anni.

Sebbene ci siano altri modi per distribuire i tuoi siti, molti di questi implicano l'interfaccia con Git Webhook o alcuni file di configurazione della distribuzione automatizzata tramite il tuo editor di codice. C'è molta potenza in questi altri strumenti, ma se hai appena iniziato con la distribuzione automatizzata, andare con qualcosa di semplice come Deploybot è il punto di partenza.

Per iniziare, registrati per un account Deploybot e connetti Github o Bitbucket al tuo account. Userò il mio account Bitbucket esistente oggi. Inizia aggiungendo un nuovo repository al tuo account Deploybot.

Una volta trovato il repository che desideri configurare per la distribuzione automatizzata, fai clic sul pulsante denominato Connetti nella parte inferiore della pagina. Questo ti riporterà alla pagina del tuo repository mentre Deploybot completa l'inizializzazione del tuo repository. Generalmente questo viene fatto in un minuto o due, quindi riempi il caffè e torna per completare la configurazione del processo di distribuzione.

Una volta impostato il repository, fai clic su di esso per accedere alla sua pagina principale. Dal momento che non abbiamo ancora impostato le informazioni sFTP, avrà una grande scatola che ti dice di configurare un server. Fare clic sul pulsante per creare un ambiente e un server.

Iniziamo con la distribuzione nel nostro ambiente di staging. Quindi etichetta il tuo server come staging. Scegli la distribuzione automatica e assicurati di impostare il ramo su staging.

Al termine, fai clic sul pulsante Salva nella parte inferiore della pagina per passare alla configurazione del server.

Nella pagina successiva etichettalo di nuovo come server di staging e inserisci le informazioni sFTP dal tuo sito. Se non sei sicuro di dove trovarli, leggi questa utile guida.

Con le informazioni sFTP inserite puoi scorrere fino in fondo e salvarle. Deploybot testerà quindi la tua connessione per assicurarsi che le informazioni che hai fornito funzionino. Ora è il momento di eseguire la nostra distribuzione iniziale per il sito per assicurarci che tutto funzioni. Aggiungo spesso un file test.txt alla distribuzione come modo semplice per verificare che la distribuzione abbia funzionato correttamente.

Per avviare la distribuzione nella cronologia dell'ambiente e fare clic su Distribuisci.

Ora vedrai una pagina con il tuo ultimo messaggio di commit git su di essa come nota che vedrai all'interno di Deploybot accanto a questa distribuzione. Per grandi cambiamenti lo cambierò, ma se cambio solo CSS o qualcosa di minore, il messaggio di commit può rimanere. Poiché si tratta di staging, ogni singolo commit nel nostro ramo di staging verrà distribuito automaticamente, il che significa che i tuoi messaggi di commit saranno quelli che verranno visualizzati. È solo il commit iniziale che dobbiamo eseguire manualmente sul nostro sito di staging.

Ora verifica che i tuoi file siano stati pubblicati nel sito di staging e possiamo impostare la distribuzione live.

Per la tua distribuzione live, assicurati di non scegliere la distribuzione automatica e assicurati di scegliere il ramo principale come origine della tua distribuzione. Vogliamo che questa sia una distribuzione manuale quando siamo pronti per inviare le modifiche al nostro sito live.

Per fare ciò dovrai controllare il tuo ramo principale, quindi unire le modifiche dal ramo di staging al ramo principale.

Puoi farlo con questi comandi.

git checkout master

git merge staging

git push origine master

Ora, quando accedi al tuo account Deploybot, sarai in grado di distribuire manualmente le modifiche proprio come abbiamo fatto con la nostra distribuzione iniziale nel nostro ambiente di staging. Per il tuo ambiente live, assicurati di modificare il messaggio di distribuzione per adattarlo alle modifiche che vengono inviate al tuo sito live. Dovresti anche creare un backup del tuo sito. Puoi farlo accedendo alla navigazione dei backup sul tuo sito e quindi creando un backup manuale.

Questo è tutto, hai la configurazione del tuo sistema di distribuzione automatizzata sia per gli ambienti di staging che per quelli live.

Altre considerazioni sulla distribuzione

Sebbene questo sistema sia un grande passo avanti per la maggior parte degli sviluppatori, non è privo di problemi. Il più grande è che se hai un sacco di modifiche stai ancora aspettando che FTP finisca di trasferire i file che sono cambiati. Ciò può significare che qualcuno visita il tuo sito e che non tutti i file che il tuo sito deve eseguire sono presenti.

Per molti clienti questo non sarà un problema, ma se è per il tuo sito, dovrai cercare di configurare un sistema di distribuzione Atomic. Questo tipo di sistema di distribuzione sposta tutti i file, verifica che funzionino correttamente e quindi modifica le impostazioni dei file sul server in modo che la nuova directory sia ora quella che esegue il tuo sito.

Il processo di collegamento a una nuova cartella richiede così poco tempo che solo un computer se ne accorgerebbe. Ciò significa anche che se riscontri un problema in un secondo momento, puoi ripristinare il collegamento di sistema alla versione precedente del sito per ripristinare la versione che funzionava. Anche in questo caso basta poco tempo e si riducono i tempi di fermo.

Qualunque cosa tu scelga di fare, smetti di usare un client FTP per distribuire i tuoi file client oggi stesso. Il piccolo costo mensile di Deploybot viene recuperato ogni volta che non commetti un errore durante la distribuzione dei tuoi file.