Share
In questa serie, diamo uno sguardo alle varie pratiche utilizzate nello sviluppo professionale di WordPress. Nel precedente articolo, abbiamo esaminato una serie di strategie e materiale di riferimento utili per la creazione di temi, plug-in e applicazioni basate su WordPress.
In questo articolo, daremo un'occhiata al controllo delle versioni e alle configurazioni ambientali che semplificano lo sviluppo, il test e l'implementazione del nostro lavoro per ridurre al minimo la quantità di errori che trovano la loro strada nelle versioni finali del nostro lavoro.
Questo argomento non è una novità In effetti, mi azzarderei a dire che la maggior parte dei lettori qui ha familiarità con Subversion e / o Git (specialmente con la popolarità di GitHub). In quanto tale, il punto di questo articolo non è tanto quello di dare un giro dei vari sistemi di controllo del codice sorgente o di creare un caso per il quale dovresti utilizzarlo ma è pensato per creare un caso perché dovresti utilizzare il controllo del codice sorgente e il modo in cui è correlato ai nostri ambienti.
Se tu sei completamente nuovo al concetto di controllo di versione, forniamo una semplice definizione di cui possiamo lavorare in modo che siamo tutti sulla stessa pagina:
Controllo versione è un'istantanea del codice sorgente in qualsiasi periodo temporale che consente di eseguire il rollback quando viene introdotto un bug e di lavorare su una nuova funzionalità senza rompere il codice esistente.
All'interno della comunità di WordPress, le persone sono spesso divise sull'opportunità o meno di considerare temi e / o software di plugin o siti web glorificati. Personalmente, credo che siano una forma di software in quanto sono soggetti a molte delle stesse pratiche:
A tal fine, lo sviluppo e il mantenimento del lavoro specifico di WordPress devono essere trattati come tali ed è lo standard del settore per fornire un livello di controllo della versione sul software.
Inoltre, il controllo della versione funziona mano nella mano con il lavoro sul progetto, testandolo e quindi distribuendolo su un server live affinché altri possano usarlo.
La maggior parte degli sviluppatori ha familiarità con i vari ambienti anche se non usano la terminologia esatta. Semplicemente definito:
Abbastanza semplice.
Il fatto è che ognuno di questi ambienti è anche strettamente correlato al controllo della versione in modo tale che, se gestito correttamente, è possibile ridurre al minimo il sovraccarico di mantenimento delle versioni e delle distribuzioni del proprio lavoro.
L'ambiente di sviluppo è la macchina su cui sviluppi effettivamente il tuo progetto. Include una copia di WordPress, il server web, il server di database, l'IDE e gli strumenti correlati che utilizzi per creare il tuo progetto.
Questo particolare ambiente è dove dovresti fare frequenti commit. Con questo, intendo che ogni volta che apporti un cambiamento significativo - sia che si tratti di una nuova funzionalità, di una risoluzione del bug o di qualcosa di simile - allora dovresti inserire il codice nel repository.
Qui, il vantaggio è che puoi facilmente eseguire il rollback, identificare e distinguere tra le modifiche nel caso in cui qualcosa vada storto durante il processo.
Una volta che hai completato una quantità significativa di modifiche (in cui tu o il tuo team determinate ciò che costituisce "significativo"), allora è il momento di contrassegnare l'insieme di modifiche e distribuire nell'ambiente di staging.
L'ambiente di staging è un server separato che assomiglia all'ambiente di produzione, ma viene utilizzato per testare il progetto prima di rilasciarlo. Comprende l'ultima versione del codice, i dati di test ed è destinato agli utenti per valutare il progetto prima di rilasciarlo. Nessuno sviluppo dovrebbe verificarsi qui.
Anche se non dovrebbe verificarsi alcuno sviluppo qui, non è raro avere vari strumenti di debug in atto per generare messaggi di log o rivedere cosa sta succedendo e uscendo dal database mentre si lavora sul sito.
Poiché gli sviluppatori spesso impegnano una serie di modifiche al repository, devono essere testate. È qui che entra in gioco l'ambiente di staging. In generale, l'ambiente di gestione temporanea corrisponde spesso a qualsiasi sia l'ultima serie di modifiche apportate al repository.
Ma questo solleva due domande:
Prima di tutto, questa è una buona cosa - significa che l'Ambiente di Staging ha raggiunto il suo scopo! Inoltre, ci dà la possibilità di rivedere il nostro codice sorgente per determinare se un bug deve essere risolto o se deve essere introdotta una nuova funzionalità.
Ed è qui che il controllo del codice sorgente è utile.
Se si è verificato un errore, è possibile inclinarsi nella direzione di ripristino della modifica, ma nell'ambiente di gestione temporanea non è necessario. Invece, si individua semplicemente dove si trova il bug, lo si risolve, si esegue il commit del codice e quindi si ridistribuisce il codice nell'ambiente di staging per il test.
Ripeti questo processo fino a quando non ci sono bug o, più precisamente, non riesci a localizzare alcun bug.
Se non riesci a localizzare alcun bug, allora hai essenzialmente quello che viene definito come una build stabile. A questo punto, puoi taggare - o timbrare, etichettare o qualsiasi altra convenzione il tuo sistema di controllo del codice sorgente - una versione del tuo codice e distribuirla nell'ambiente di produzione.
Naturalmente, c'è la possibilità che un bug possa essere scoperto dopo essere stato distribuito nell'ambiente di produzione. In tal caso, dovrebbe essere intrapresa un'azione speciale.
L'ambiente di produzione è sinonimo del sito live. È qui che gli utenti effettivi stanno creando, gestendo e interagendo con i dati reali. Nessuno sviluppo dovrebbe verificarsi qui.
C'è molto poco da dire sull'ambiente di produzione per quanto riguarda lo sviluppo. Dopotutto, questo non dovrebbe essere altro che il luogo in cui il codice sorgente viene distribuito affinché altri possano usarlo.
Ma c'è una possibilità che un bug possa essere rilasciato qui. Quando questo accade, Questo è quando dovrebbe verificarsi un rollback. In poche parole, un rollback è quando si prende l'ultima serie di modifiche e si annulla letteralmente la distribuzione ripristinando il progetto nel suo stato precedente.
Prima di eseguire un rollback, vale la pena notare eventuali passaggi di ricreazione in modo che sia possibile riprodurli sia nell'ambiente di gestione temporanea che nell'ambiente di sviluppo per risolvere correttamente il problema.
Da qui, eseguire lo sviluppo necessario per risolvere il problema, commettere un'altra modifica, distribuirla nell'ambiente di gestione temporanea e distribuirla nell'ambiente di produzione assumendo che superi i test.
Ovviamente, questo post specifico copre concetti ad alto livello: non stiamo esplorando quali sono i sistemi di controllo delle versioni migliori, né stiamo cercando quali strumenti siano i migliori per il tuo particolare sistema operativo. Questi argomenti non rientrano nell'ambito di questo post e sono meritevoli della propria serie.
Tuttavia, nell'ambito del concetto di sviluppo di WordPress professionale, queste pratiche possono ovviamente dimostrarsi utili nello sviluppo, test e distribuzione (e rollback) delle versioni del progetto.
Nel post finale, daremo un'occhiata ad alcuni dei vari strumenti disponibili che ci permetteranno di diagnosticare molti errori nel nostro ambiente di sviluppo locale con l'intento di impedire a molti di loro di raggiungere anche l'ambiente di staging.
Accentsconagua