Guardrail del progetto: ambienti di fornitura

Questa serie di brevi articoli è composta da alcune cose che ho imparato negli ultimi anni eseguendo progetti basati nell’area in cui noi (supponendo che tu stia leggendo questo proveniente dalla mia stessa parte del settore 🙂) opera.

Se ti stai solo imbattendo in questo, la serie copre alcuni fattori importanti per un progetto :

1. Non ci dovrebbe essere alcun " design by comitato”. “
2. Nessun altro che il team di sviluppo principale dovrebbe essere in grado di fornire sviluppo, staging e produzione.
3. Nessuno dovrebbe essere in grado di scrivere in produzione tranne il team di sviluppo (e anche in questo caso dovrebbe esserci un processo di distribuzione).

Non mi piace molto fare regole dure e veloci come questa in particolare perché le cose cambiano nel tempo o per necessità o per più esperienza. Questo è il motivo per cui mi piacciono le "linee guida".

Ma nel momento in cui scrivo, queste sono le cose che vedo giocare.

Ambienti di fornitura

Negli ultimi anni, abbiamo fatto molti progressi nella rapidità con cui possiamo eseguire il provisioning dei nostri sistemi in modo che tutti si rispecchino l’un l’altro (o in generale così). Ciò include le nostre scatole di sviluppo, il modo in cui le nostre macchine locali rispecchiano lo staging e come lo staging rispecchia la produzione.

Fornire un nuovo ambiente, più o meno. Rotola con esso.

Cioè se "funziona sulla mia macchina" dovrebbe effettivamente essere vero. Non è una scusa per non essere in grado di riprodurre un bug.

E quando è vero, è probabile che lo sia anche sulle macchine altrui, sulla messa in scena e sulla produzione. E questo è carino, vero? Voglio dire, facciamo girare le nostre scatole, distribuiamo i nostri script o facciamo quello che facciamo e poi abbiamo la configurazione di cui abbiamo bisogno.

Quindi cosa significa fare il provisioning degli ambienti? Dipende dall’ambiente a cui ti riferisci.

Com’è davvero questo aspetto?

Se stai lavorando in WordPress, cosa che presumo tu sia se stai leggendo questo, allora presuppone che tu stia eseguendo un server Web, un database e almeno PHP.

Un ambiente di sviluppo può essere simile al seguente:

• Apache di Nginx ,
• MySQL che è il più comune,
• Almeno PHP 5.2.4 (con PHP 7.1 consigliato),
• O qualcosa di paragonabile.

Potresti anche usare qualcosa come Laravel Valet o qualcosa come VVV. Tutto dipende dalla natura del tuo lavoro.

Inoltre, a seconda della natura della tua attività, potresti avere un IDE assegnato a te insieme a vari file di configurazione per applicare determinate regole.

E il resto degli ambienti?

Come di solito:

• lo sviluppo si riferisce all’installazione sulla macchina locale,
• lo staging si riferisce all’area in cui tu e gli stakeholder potete testare,
• e la produzione è dove risiede l’applicazione.

Ma anche questo sembra diverso a seconda di dove lavori, come è organizzato il tuo lavoro e così via. Non si tratta tanto di come viene utilizzato, ma di come viene utilizzato.

Messa in scena

Di solito viene eseguito il provisioning su un server (o un gruppo di server a seconda delle dimensioni del progetto) in cui è possibile distribuire il codice più recente per il test. Può includere funzionalità parziali, dati di test e solo un sottoinsieme di informazioni dalla produzione (se si sceglie di estrarre tali informazioni, ovvero il database, dall’ambiente di produzione).

Ciò offre a te e alle altre parti interessate la possibilità di rivedere ciò che sta uscendo e come funzionerà nella produzione senza doversi preoccupare di distruggere qualsiasi cosa sensibile.

Il codice viene comunemente distribuito da un ramo, solitamente master, dal tuo repository Git (se è quello che stai usando). E strumenti come DeployBot, CircleCI, Travis CI, GrumPHP, Behat e così via vengono utilizzati anche per valutare la qualità del codice, eseguire qualsiasi test automatizzato e infine distribuire il codice.

Alla fine, verrà eseguito il provisioning di ogni ambiente in modo da poter essere rapidamente replicato su macchine locali, server di staging e server di produzione. Inoltre, dovrebbe essere facile eseguire il push e il pull dei dati tra di loro per semplificare il lavoro con i dati.

Produzione

Infine, la produzione è tutta incentrata sul progetto di funzionamento vero e proprio; Ciò significa che ha il server, l’applicazione e il database in esecuzione insieme e viene utilizzato dagli utenti.

Ciò significa anche che il codice è in una posizione stabile. È probabile che siano in atto meccanismi di registrazione che avviseranno il team di sviluppo di eventuali problemi. Non dovrebbe verificarsi alcuna modifica del codice in questo ambiente senza che sia stato prima superato il QA o lo staging.

E i processi in atto?

Ok, quindi supponiamo che tu stia lavorando con una configurazione tradizionale, per mancanza di un termine migliore, in cui tutte le tue distribuzioni vengono eseguite tramite S/FTP in un ambiente di produzione (o addirittura staging). In questo modo, gli utenti possono estrarre i file, apportare le modifiche e ripristinarli.

Non va bene.

Ciò significa che chiunque disponga delle credenziali può accedere, apportare modifiche e ignorare il controllo del codice sorgente, l’integrazione continua, gli strumenti di garanzia della qualità e così via, eseguire le modifiche desiderate.

Mina l’intero processo messo in atto. Questa non solo bypassa la procedura standard (che è in atto per un motivo, ovviamente), ma finisce per rompere il codice che uno sviluppatore o un team di sviluppatori ha sulle proprie macchine principalmente perché ciò che è in produzione non è più sincronizzato con il repository del codice.

Inoltre, questo codice potrebbe essere distribuito tra rami che devono ancora essere uniti o distribuiti. Questo ci lascia con una varietà di situazioni in cui sviluppatori e clienti hanno interrotto alcune parti del processo di compilazione e quindi l’intero progetto.

Quando arriva il momento di controllare la produzione, non è sincronizzata con lo sviluppo e la messa in scena e nessuno sa perché. Quando arriva il momento di implementare, le modifiche vengono sovrascritte e i responsabili hanno perso ciò che pensavano di vedere.

Cosa deve fare una squadra?

Non so se c’è una risposta giusta a questa domanda, ma più a lungo lavoro in questo settore, più credo che l’azienda – o le aziende – responsabili della creazione della soluzione per il cliente dovrebbero avere il controllo del processo dalla fine. finire.

• I designer sono responsabili della gestione delle loro aree di creazione di concetti, mock, creazione di modelli demo e sollecitazione di feedback,
• I Project Manager sono responsabili della comunicazione con i reparti,
• Gli sviluppatori sono responsabili dell’implementazione della soluzione e del collegamento tra il lavoro dei progettisti e il back-end funzionale,
• Il cliente è responsabile della revisione delle modifiche, della fornitura di feedback e della fornitura di qualsiasi altra informazione necessaria per completare l’attività.

Ciò significa che quando si tratta di configurare il dominio, l’hosting, gli ambienti, il controllo della versione, il processo di compilazione e l’integrazione continua, e tutto ciò che ho trascurato di menzionare ricade direttamente sul team di sviluppo.

Rimani in trincea, rimani sul bersaglio (ma fai attenzione a chi ti circonda).

In poche parole, queste non sono responsabilità del cliente né dovrebbero esserlo. I limiti di responsabilità dovrebbero essere stabiliti, mantenuti e rispettati in tutti i team, non solo sviluppatori e clienti o clienti e designer o designer e sviluppatori e così via.

Qual è il prossimo?

Nel prossimo post parlerò delle responsabilità che gli sviluppatori (e altre parti interessate) hanno nella manutenzione degli ambienti per il codice.

Cioè, chi dovrebbe essere responsabile di cosa e chi ha accesso per leggere e scrivere quali dati e come possono in definitiva influenzare il risultato del progetto.