- \n
- Non ci dovrebbe essere alcun " design by comitato”.<\/a> “<\/li>\n
- Nessun altro che il team di sviluppo principale dovrebbe essere in grado di fornire sviluppo, staging e produzione.<\/li>\n
- 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).<\/li>\n<\/ol>\n
Non mi piace molto fare regole dure e veloci come questa in particolare perch\u00e9 le cose cambiano nel tempo o per necessit\u00e0 o per pi\u00f9 esperienza. Questo \u00e8 il motivo per cui mi piacciono le "linee guida".<\/p>\n
Ma nel momento in cui scrivo, queste sono le cose che vedo giocare.<\/p>\n
Ambienti di fornitura<\/h2>\n
Negli ultimi anni, abbiamo fatto molti progressi nella rapidit\u00e0 con cui possiamo eseguire il provisioning dei nostri sistemi in modo che tutti si rispecchino l’un l’altro (o in generale cos\u00ec). Ci\u00f2 include le nostre scatole di sviluppo, il modo in cui le nostre macchine locali rispecchiano lo staging e come lo staging rispecchia la produzione.<\/p>\n
Fornire un nuovo ambiente, pi\u00f9 o meno. Rotola con esso.<\/p>\n
Cio\u00e8 se "funziona sulla mia macchina" dovrebbe effettivamente essere vero. Non \u00e8 una scusa per non essere in grado di riprodurre un bug.<\/p>\n
E quando \u00e8 vero, \u00e8 probabile che lo sia anche sulle macchine altrui, sulla messa in scena e sulla produzione. E questo \u00e8 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.<\/p>\n
Quindi cosa significa fare il provisioning degli ambienti? Dipende dall’ambiente a cui ti riferisci.<\/p>\n
Com’\u00e8 davvero questo aspetto?<\/h3>\n
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.<\/p>\n
Un ambiente di sviluppo pu\u00f2 essere simile al seguente:<\/p>\n
- \n
- Apache<\/a> di Nginx<\/a> ,<\/li>\n
- MySQL che \u00e8 il pi\u00f9 comune,<\/li>\n
- Almeno PHP 5.2.4 (con PHP 7.1 consigliato),<\/li>\n
- O qualcosa di paragonabile.<\/li>\n<\/ul>\n
Potresti anche usare qualcosa come Laravel Valet<\/a> o qualcosa come VVV<\/a>. Tutto dipende dalla natura del tuo lavoro.<\/p>\n
Inoltre, a seconda della natura della tua attivit\u00e0, potresti avere un IDE assegnato a te insieme a vari file di configurazione per applicare determinate regole<\/a>.<\/p>\n
E il resto degli ambienti?<\/h3>\n
Come di solito:<\/p>\n
- \n
- lo sviluppo si riferisce all’installazione sulla macchina locale,<\/li>\n
- lo staging si riferisce all’area in cui tu e gli stakeholder potete testare,<\/li>\n
- e la produzione \u00e8 dove risiede l’applicazione.<\/li>\n<\/ul>\n
Ma anche questo sembra diverso a seconda di dove lavori, come \u00e8 organizzato il tuo lavoro e cos\u00ec via. Non si tratta tanto di come viene utilizzato, ma di come viene utilizzato.<\/p>\n
Messa in scena<\/h4>\n
Di solito viene eseguito il provisioning su un server (o un gruppo di server a seconda delle dimensioni del progetto) in cui \u00e8 possibile distribuire il codice pi\u00f9 recente per il test. Pu\u00f2 includere funzionalit\u00e0 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).<\/p>\n
Ci\u00f2 offre a te e alle altre parti interessate la possibilit\u00e0 di rivedere ci\u00f2 che sta uscendo e come funzioner\u00e0 nella produzione senza doversi preoccupare di distruggere qualsiasi cosa sensibile.<\/p>\n
Il codice viene comunemente distribuito da un ramo, solitamente master, dal tuo repository Git (se \u00e8 quello che stai usando). E strumenti come DeployBot<\/a>, CircleCI<\/a>, Travis CI<\/a>, GrumPHP<\/a>, Behat<\/a> e cos\u00ec via vengono utilizzati anche per valutare la qualit\u00e0 del codice, eseguire qualsiasi test automatizzato e infine distribuire il codice.<\/p>\n
Alla fine, verr\u00e0 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.<\/p>\n
Produzione<\/h4>\n
Infine, la produzione \u00e8 tutta incentrata sul progetto di funzionamento vero e proprio; Ci\u00f2 significa che ha il server, l’applicazione e il database in esecuzione insieme e viene utilizzato dagli utenti.<\/p>\n
Ci\u00f2 significa anche che il codice \u00e8 in una posizione stabile. \u00c8 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.<\/p>\n
E i processi in atto?<\/h3>\n
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.<\/p>\n
Non va bene.<\/p>\n
Ci\u00f2 significa che chiunque disponga delle credenziali pu\u00f2 accedere, apportare modifiche e ignorare il controllo del codice sorgente, l’integrazione continua, gli strumenti di garanzia della qualit\u00e0 e cos\u00ec via, eseguire le modifiche desiderate.<\/p>\n
Mina l’intero processo messo in atto. Questa non solo bypassa la procedura standard (che \u00e8 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\u00e9 ci\u00f2 che \u00e8 in produzione non \u00e8 pi\u00f9 sincronizzato con il repository del codice.<\/p>\n
Inoltre, questo codice potrebbe essere distribuito tra rami che devono ancora essere uniti o distribuiti. Questo ci lascia con una variet\u00e0 di situazioni in cui sviluppatori e clienti hanno interrotto alcune parti del processo di compilazione e quindi l’intero progetto.<\/p>\n
Quando arriva il momento di controllare la produzione, non \u00e8 sincronizzata con lo sviluppo e la messa in scena e nessuno sa perch\u00e9. Quando arriva il momento di implementare, le modifiche vengono sovrascritte e i responsabili hanno perso ci\u00f2 che pensavano di vedere.<\/p>\n
Cosa deve fare una squadra?<\/h3>\n
Non so se c’\u00e8 una risposta giusta a questa domanda, ma pi\u00f9 a lungo lavoro in questo settore, pi\u00f9 credo che l’azienda – o le aziende – responsabili della creazione della soluzione per il cliente dovrebbero avere il controllo del processo dalla fine. finire.<\/p>\n
- \n
- I designer sono responsabili della gestione delle loro aree di creazione di concetti, mock, creazione di modelli demo e sollecitazione di feedback,<\/li>\n
- I Project Manager sono responsabili della comunicazione con i reparti,<\/li>\n
- Gli sviluppatori sono responsabili dell’implementazione della soluzione e del collegamento tra il lavoro dei progettisti e il back-end funzionale,<\/li>\n
- Il cliente \u00e8 responsabile della revisione delle modifiche, della fornitura di feedback e della fornitura di qualsiasi altra informazione necessaria per completare l’attivit\u00e0.<\/li>\n<\/ul>\n
Ci\u00f2 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\u00f2 che ho trascurato di menzionare ricade direttamente sul team di sviluppo.<\/p>\n
![\"Guardrail](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-166423-61e793a807c63.jpg\")
<\/a><\/p>\n