Come automatizzo le attività di build-publish per il mio server web?

Question

Come automatizzo le attività di build-publish per il mio server web?

#1 da (5 voti)

4

Sto sviluppando un server web node.js che avrà incorporato il codice sorgente del server e della parte client in una volta . Voglio dire, il mio server web è a livello isomorfico. questo significa che la modifica del codice sorgente della parte client può dare qualche effetto sul codice lato server.

così quando ho finito di sviluppare (correggendo bug, ecc.) la mia applicazione web server abbastanza, l'avrei compilata e caricata sul mio server web fisico e riavviata l'applicazione server web per applicare (eseguire) i codici sorgente compilati .

In questa situazione, il mio problema è appena uscito:

How do I automate all the publishing (building, uploading, restarting, etc.) task?

Per ora, sto implementando nuovi codici sorgente nei seguenti passaggi:

1. found a bug or required feature
2. develop to implement features or fix problems
3. build the web server or client source codes
4. upload it to the physical web server
5. restart web server application that is run on the physical web server

questo è un compito abbastanza fastidioso quando ho dei piccoli problemi da risolvere sul codice sorgente. (come errori di battitura)

Avevo google su "CI" o "CD", ma ho alcune informazioni su Jenkins ma non sono abbastanza per darmi la risposta perché la maggior parte di loro usa Git come loro (forse) middleware per pubblicare i loro codice. Non voglio pubblicare alcuna parte del mio codice sorgente pubblicamente.

Scriverò alcuni script bash che automatizzeranno le pubblicazioni ma voglio realizzarlo come se fossi in un ambiente a livello aziendale. comunque, non ho assolutamente esperienza di quanto sia conveniente il processo di distribuzione delle grandi aziende. quindi non so come realizzano il loro lavoro sul mio problema.

Inoltre, nell'ambiente node.js, devo riavviare il server Web per applicare i codici sorgente incorporati che vengono caricati sul server Web fisico. Tuttavia, ciò impedirà agli utenti di accedere all'app Web che ho creato mentre il server Web si sta riavviando. questo suona davvero critico.

quindi sarei davvero grato se qualcuno mi facesse sapere se esiste un modo tagliente per applicare nuovi codici sorgente senza riavviare l'applicazione server web nell'ambiente node.js.

continuous-integration automation continuous-delivery node.js

posta Sophia 12.08.2018 - 10:13

fonte

1 risposta

Leggi altre domande sui tag continuous-integration automation continuous-delivery node.js

Ciclo while e do-while nel metodo della casella bianca del test del ciclo Pattern generico di repository + EF e unità di lavoro

score 5 · Accepted Answer

Uno script Bash è esattamente come accade in molte aziende. Evita i passaggi che devi eseguire manualmente. Automatizzali in modo tale che devi solo avviare il processo e puoi quindi sederti. Essere in grado di eseguire una distribuzione con un singolo comando abilita i flussi di lavoro "Distribuzione continua": se una distribuzione è super facile e ripetibile, è possibile eseguirli spesso, per piccole modifiche, e il rischio di distribuzione è ridotto.

Ci sono spesso considerazioni aggiuntive:

la versione esatta che è stata distribuita dovrebbe essere in controllo di versione
- e lo stato del controllo della versione deve essere sempre in stato di distribuzione
prima della distribuzione, dovrebbe essere eseguita una suite di test automatizzata

Ciò dà origine all'idea di eseguire la distribuzione tramite un server di build (server CI) come Jenkins: ogni volta che si esegue il commit di una nuova versione, il server di compilazione recupera il codice, lo costruisce e lo collauda e quindi (facoltativamente) distribuisce quello codice automaticamente. Ciò consente di spostarsi rapidamente, ma richiede una ragionevole suite di test automatizzata per evitare regressioni accidentali.

Non tutte queste pipeline di distribuzione sono costituite da script di Bash. Uno specifico strumento CI può avere le proprie convenzioni o plugin che è possibile utilizzare piuttosto che scrivere uno script Bash che esegue alcuni comandi SSH. Molti fornitori di servizi cloud offrono anche API. In un certo senso, un Dockerfile è anche solo uno script Bash glorificato. Ma una sceneggiatura per legare tutto insieme non è sbagliata.

Il problema "la distribuzione richiede un riavvio del server" non è generalmente evitabile, ma non è necessariamente un grosso problema. L'approccio abituale è quello di eseguire la tua app web dietro un proxy o un gateway. Durante la distribuzione si avvia un secondo server con la nuova versione, quindi si consente al gateway di spostare il traffico sul nuovo server fino a quando il vecchio server non può essere spento e, in caso di problemi, la distribuzione può essere ripristinata rapidamente spostando il traffico sul vecchia versione. Questo modello è anche noto come distribuzione verde-blu. Qui il server potrebbe essere un processo, un container o una macchina virtuale. Se devi distribuire senza tempi di inattività dipende dal tuo traffico. Per i siti di piccole dimensioni, alcuni secondi di inattività sono solitamente impercettibili.

Su una scala molto ampia con un'architettura di microservice ridondante che viene eseguita su un cluster (ad esempio gestita tramite Kubernetes), l'implementazione comporta la sostituzione dei nodi del cluster uno per uno e il monitoraggio dei tassi di errore e altre metriche delle prestazioni durante la distribuzione. Poiché tutto è ridondante, qualsiasi problema di distribuzione interesserà solo pochissimi utenti (o forse nessuno: una strategia di test consiste nell'inviare richieste reali a una nuova versione ma ignorare le risposte o confrontare le risposte alla versione precedente).

Ma se non operi su quella scala, non hai bisogno di questo approccio high-end. Inoltre, non hai bisogno dei costi dell'infrastruttura necessaria. Un semplice script bash ha già una lunga strada.

Ulteriori letture:

L'app a dodici fattori . Una guida breve, di base e importante per le migliori pratiche di architettura e implementazione di app Web. Potrebbe avere un leggero pregiudizio nei confronti delle pratiche orientate a Heroku, ma è abbastanza ragionevole e facilmente generalizzabile.
Come distribuire il software di Zach Holman. Una lettura lunga ma buona su concetti di distribuzione di alto livello. Presume una maturità organizzativa che non è applicabile per le tue circostanze, ma fornisce background e contesto.
GitHub Flow : un breve articolo di marketing di GitHub che presenta un semplice flusso di lavoro orientato al team nel contesto della distribuzione continua. (Il nome non deve essere confuso con Git Flow non correlato). Nota che GitHub e Git in generale non richiedono mai che tu pubblichi il tuo codice al pubblico. Tuttavia, i server di build e gli strumenti simili hanno bisogno di accedere a un repository di controllo di versione e il modo più semplice per ottenerlo è pagare un'altra azienda per ospitare il repository (è possibile anche ospitarla su un proprio server). Prendi in considerazione anche concorrenti come Gitlab o Bitbucket, che integrano anche direttamente alcune funzionalità di CI.