Modifica delle configurazioni di ambiente multipli e dei problemi di distribuzione di Webpack utilizzando vue-cli

Vue è diventato così popolare ora in parte grazie a strumenti di creazione di architetture ufficiali come Vue-cli, che ha semplificato significativamente il costo di configurazione dell'ambiente per i principianti, ma nella pratica del business, spesso abbiamo bisogno di implementare altre funzioni per modificare webpack. Questo articolo esplorerà le esigenze aziendali reali, prima di imparare il modello generato da vue-cli, poi procedere con le modifiche correlate.

Cartella di modello generata da Vue-cli

├── README.md
├── build
│ ├── build.js
│ ├── check-versions.js
│ ├── dev-client.js
│ ├── dev-server.js
│ ├── utils.js
│ ├── webpack.base.conf.js
│ ├── webpack.dev.conf.js
│ └── webpack.prod.conf.js
├── config
│ ├── dev.env.js
│ ├── index.js
│ └── prod.env.js
├── index.html
├── package.json
├── src
│ ├── App.vue
│ ├── assets
│ │ └── logo.png
│ ├── components
│ │ └── Hello.vue
│ └── main.js
└── static

Il punto principale che questo articolo si concentra è

build - codice delle task di compilazione

config - file di configurazione di webpack

package.json - informazioni di base del progetto

Non esporrò in dettaglio il significato di ogni riga della configurazione di webpack, si prega di consultare l'analisi del file di configurazione webpack del framework di avvio Vue2.0

Richiesta comune: configurazione e distribuzione multi-ambiente

Il template generato da Vue-cli è configurato solo con npm run dev, npm run build, questa riga di script va a avviare il servizio di ambiente di sviluppo e eseguire il pacchetto. Mentre il normale flusso di sviluppo aziendale avrà almeno sviluppo, simulazione di test, ambiente di produzione, e gli indirizzi dei server di richiesta del servizio per ciascun ambiente o alcune configurazioni parametriche saranno diversi, e durante la distribuzione è necessario pubblicare su più server, quindi è necessario eseguire script automatizzati per costruire e distribuire.

Prima dobbiamo chiarire questa questione, citiamo un articolo, autore: Zheng Haibo, link, fonte: Zhihu

Questo non ha nulla a che fare con Vue, è un problema comune: dove costruire il codice. Se il server del proponente si riferisce al server in esecuzione, né i due sono buone scelte. Molti nuovi arrivati, inclusi io prima di lavorare, pensavano che la distribuzione del codice fosse così

Ma in una grande azienda di internet può essere più complicato. Le seguenti descrizioni sono pratiche comuni e alcuni processi sono semplificati, solo per facilitare la comprensione dei nuovi arrivati. L'invio di codice al server git o svn, presta attenzione che qui si tratta di file sorgente, non dei file costruiti

2. Il server di costruzione tenterà di scaricare la versione di codice da pubblicare dal server git e completare l'installazione delle dipendenze qui, come Vue di cui parla il proponente. E costruire i file da distribuire, questi file saranno generalmente compressi in un pacchetto compresso per la gestione

3. Dopo la costruzione, il pacchetto di distribuzione verrà caricato sul centro di trasbordo: il cluster del server di gestione dei file

4. I server in esecuzione generalmente non sono singoli, ma un cluster, questi n server prenderanno il pacchetto compresso della versione corrispondente dal server di file e lo decomprimeranno per eseguire infine.

　

In effetti, c'è un chiaro ordine di sequenza di processo qui, se tutto è fatto manualmente, sarà molto fastidioso, quindi di solito nelle grandi aziende ci sarà una piattaforma di deploy automatico per统筹 completare questi lavori. In realtà, come sviluppatore, è sufficiente cliccare su "deploy one click" per completare tutto il contenuto sopra menzionato.

Ad esempio, se si utilizza un webhook automatico di notifica per il deploy automatico fornito da piattaforme come gitlab, github, una versione stabile del codice è stata completata e inviata (Push Event). Non dobbiamo nemmeno cliccare sul pulsante. Questo è un caso tipico di separazione di costruzione e distribuzione, con molti vantaggi, come garantire che la costruzione sia un unico codice, evitare la possibilità di costruzione multi-ambiente non coerente. Costruire è un'operazione ad alta spesa, potrebbe causare instabilità del server in esecuzione, può essere rapidamente rolled back o ripristinato, non è necessario ricostruire codice della stessa versione ...

Dopo aver detto così tanto, il pacchetto e la costruzione non sono affari semplici, quindi è necessario un strumento di automazione per la configurazione. Gli schemi già maturi sono costruire un container di applicazione di docker per la costruzione e la distribuzione. Tuttavia, non sono molto familiarizzati con questo, quindi chi sa condividere?

Sommario

Come è stato introdotto dall'editoriale, qui sono state presentate le configurazioni e le questioni di distribuzione di Webpack multi-ambiente, spero che possano essere utili a tutti. Se avete qualsiasi domanda, lasciate un commento e l'editoriale risponderà tempestivamente. In questo senso, anche un grande ringraziamento per il supporto alla guida urla!

Dichiarazione: il contenuto di questo articolo è stato tratto da Internet, i diritti d'autore appartengono agli autori originali, il contenuto è stato contribuito autonomamente dagli utenti di Internet e caricato autonomamente, il sito web non detiene i diritti di proprietà, non è stato elaborato manualmente e non assume responsabilità legali correlate. Se trovi contenuti sospetti di violazione del copyright, ti preghiamo di inviare un'e-mail a notice#oldtoolbag.com (al momento dell'invio dell'e-mail, sostituisci # con @) per segnalare, fornendo prove pertinenti. Una volta verificata, il sito web eliminerà immediatamente il contenuto sospetto di violazione del copyright.