È consigliabile distribuire un progetto sul file server per file manualmente?

26

La società per cui lavoro per ora non implementa la consegna continua. Distribuiamo ancora manualmente il progetto sul server, file per file. Qual è la migliore pratica: distribuire manualmente un artefatto di progetto per ogni distribuzione o continuare a eseguire la distribuzione file per file?

deployment server devops

— Jake Muller
fonte

12

Non esiste nemmeno una "pratica per tutte le situazioni" in remoto per questo compito.

— whatsisname

26

Normalmente vorrei collegarmi a Perché fare una domanda sulle "migliori pratiche" è una cosa negativa? Penso che possiamo essere tutti d'accordo sul fatto che questa è la peggiore pratica. Si colloca leggermente al di sopra di "dare fuoco al server".

3

rilevante: en.wikipedia.org/wiki/…

— Jens Schauder,

9

Ho il sospetto che OP stia ponendo questa domanda perché conosce già la risposta, e il suo posto di lavoro è Doing It Wrong (tm), e OP sta cercando di raccogliere prove per fare un caso per cambiare il modo in cui fanno le cose.

— user1936

2

Lo abbiamo fatto in questo modo nel secondo millennio. Dovrebbe andare bene! ;)

— Don Branson,

103

Qual è la migliore pratica? distribuire manualmente un artefatto di progetto per ogni distribuzione o continuare a fare il file mediante distribuzione di file?

Né.

La migliore pratica è automatizzare la distribuzione in modo completo ed esclusivo. Ciò significa che nessuno può mettere nulla manualmente su un server.

"Per riassumere il riassunto del sommario: le persone sono un problema." (Douglas Adams)

Le persone fanno errori. Se uno dei file che si dimentica di copiare è una "libreria" condivisa che è stata ampiamente modificata, è possibile arrestare l'intero sito di produzione.

— Phill W.
fonte

17

@JohnHamilton Se automatizzare la compilazione è un compito difficile, questo a sua volta è qualcosa da risolvere a lungo termine. Non è necessario disporre di ambienti di sviluppo, test e pre-produzione completi di distribuzione completamente automatizzata, ma la creazione di un pacchetto di distribuzione standard dovrebbe essere una pratica standard.

— Neil,

20

Ehm, la dimensione dell'azienda non è davvero il problema (in una certa misura). Il costo sarà correlato alla misura in cui la distribuzione è automatizzata e anche alla complessità dell'ambiente di produzione. Ma c'è un gradiente di automazione e un gradiente di "costo" (tempo / denaro) a partire da cose semplici come uno script per copiare l'output della generazione nella produzione (piccolo investimento con risparmi immediati sui costi tangibili) e aumentare da lì, ed è più dipendente sul buy-off della direzione rispetto alle dimensioni dell'azienda.

— BurnsBA

39

@JohnHamilton: Una società più piccola che è gestita male potrebbe illudersi nel pensarlo, certo. L'automazione della copia di file non è esattamente un compito difficile e il costo di far svolgere regolarmente qualsiasi persona occupata supererà enormemente il costo di scrivere anche lo script più banale per farlo.

— GManNickG,

8

@JohnHamilton: il costo dell'automazione deve essere valutato rispetto al rischio di errori commessi durante l'implementazione manuale.

— Robert Harvey,

7

Non hai nemmeno necessariamente bisogno di Jenkins. Solo uno script archiviato con un sacco di comandi scp (o qualunque cosa tu usi durante il caricamento manuale) sarebbe un miglioramento.

— user253751

14

I passaggi manuali richiedono molto impegno e sono rischiosi: potresti dimenticare un file necessario. Forse non tutti nel tuo team sanno quali file devono essere copiati. Tutti questi problemi rendono le distribuzioni grandi, scoraggianti e rare - completamente inutili. L'automazione si rivolge a questi.

Anche il passaggio di automazione più semplice può avere grandi vantaggi, poiché le implementazioni diventano banali. Uno script che copia i file o gli artefatti tramite (S) FTP o Rsync o un'altra tecnologia è un ottimo primo passo. In seguito è possibile espandere quello script per eseguire automaticamente i passaggi pre-distribuzione e post-distribuzione sul server, come il riavvio dei servizi.

— amon
fonte

Se il numero totale di server è 2 o inferiore, il manuale è meno rischioso di quello automatico. Automatico richiede un controllo completo dei bug. Non ho mai visto una banale soluzione automatica che sia rimasta banale.

— Giosuè,

3

@Joshua Non sono sicuro che il numero di server dovrebbe essere un fattore qui. L'automazione ha valore anche quando si distribuisce più volte sullo stesso server. La domanda è: di chi ti fidi di più: il computer per eseguire fedelmente uno script che ha funzionato una volta o la tua capacità di ricordare tutte le fasi necessarie ogni volta? Come essere umano fallibile e smemorato, ho una forte preferenza per non fare cose manualmente. A volte scrivo anche attività una tantum solo per poter rivedere i comandi prima di eseguirli. È molto meno rischioso che fare manualmente cose casuali fino a quando non funziona!

— Amon,

Ho una vasta esperienza in entrambi i modi. Quello che faccio per la distribuzione manuale è l'installazione di xcopy, quindi non ci sono davvero passaggi da dimenticare.

— Giosuè,

9

La migliore pratica sarebbe quella di implementare un processo automatizzato di qualche tipo.

Fai attenzione a verificare che non vi sia un motivo speciale per l'approccio "file per file" che dovresti prendere in considerazione.

— Ewan
fonte

1

Faccio questa domanda perché voglio solo assicurarmi che non sia assolutamente la migliore pratica al mondo. Mi chiedo se ci sono ancora aziende / sviluppatori che distribuiscono ancora manualmente le loro app / progetti, e ciò che peggiora è la distribuzione file per file ogni iterazione di sviluppo.

— Jake Muller,

4

La migliore domanda da porsi è "perché lo facciamo in questo modo?" Non riesco a pensare a un motivo, ma so che ad alcune aziende piace tenere una mano manuale sul grilletto per così dire

— Ewan

8

@JakeMuller Quello che dovresti leggere tra le righe di questa risposta è che le decisioni dovrebbero essere prese ragionando sulla situazione, non sulla schiavizzata aderenza a ciò che qualcuno senza conoscenza aveva dichiarato di avere sempre la risposta giusta.

— Blrfl,

Il motivo dell'approccio file per file potrebbe essere che sono dipendenze tra i file e quindi gli aggiornamenti dei file vengono distribuiti prima delle modifiche ad altri file che dipendono da quei file. L'aggiornamento dei file nell'ordine sbagliato potrebbe frenare brevemente il sistema.

— bdsl,

6

Con la consegna continua (o la distribuzione, in realtà) e lo spostamento manuale di ogni file, stai osservando i due estremi. È perfettamente comprensibile che non sia possibile / non si desideri creare (ancora) una pipeline completamente automatizzata. Tuttavia, dovresti considerare di automatizzare parti del processo.

Spostare ogni file a mano è piuttosto rischioso e potresti mitigarlo, ad esempio taggando il tuo repository di codici, controllando quel tag nel tuo computer, costruendo i tuoi artefatti e caricandoli sul tuo server. Ognuno di questi passaggi può essere automatizzato in modo da essere eseguito con pochi clic del mouse e ciò ridurrà notevolmente il rischio di dimenticare un file o di spingere accidentalmente per produrre alcuni file extra.

Automatizza ciò che puoi, una volta alla volta. Il fatto che non ci si possa permettere una pipeline di CD completamente automatizzata non dovrebbe scoraggiare dall'automazione di alcune parti.

— Blueriver
fonte

1

La migliore pratica sarebbe quella di fare un'analisi costi / benefici per la tua particolare implementazione per la tua particolare azienda.

La risposta generale è "non fare le cose manualmente, automatizza". Questa è generalmente la risposta giusta per i tipi generali di società. L'uniformità delle risposte che stai ricevendo dovrebbe essere un'indicazione della forza con cui la comunità ritiene che siano le migliori pratiche. Se la tua azienda ritiene che l'automazione non sia lo strumento giusto, dovrebbe avere qualche idea su cosa li rende unici. Tale unicità dovrebbe essere presa in considerazione nel processo decisionale. Non esistono "best practice" quando il set di campioni è 1.

Domande come "quanti file" e "con che frequenza vengono aggiornate" e "quali sono le conseguenze di una rottura" e "quanto velocemente è possibile ripristinare un brutto cambiamento" sono domande importanti a cui rispondere. Se automatizzi, molte di queste domande diventano irrilevanti, ma sono essenziali per assegnare correttamente i costi e i vantaggi di un processo di aggiornamento manuale.

— Cort Ammon - Ripristina Monica
fonte

1

Ci sono molte sfumature di grigio tra la copia manuale file per file e la consegna continua.

Inizia riducendo la complessità del processo di distribuzione, ad esempio utilizzando un file zip, un pacchetto in stile rpm, un'infrastruttura come strumento di gestione del codice (come burattino o cuoco) o anche solo un semplice script che copia i file per te da un area di gestione temporanea sul server ftp.

I processi di distribuzione con più passaggi manuali hanno maggiori probabilità di avere errori (e quindi fallire) - come altri hanno già detto, eliminano l'elemento umano.

Non è necessario implementare la consegna continua completa (che è costosa e richiede impegno / investimento / innovazione nel tempo) - iniziare in modo semplice, farlo funzionare, dimostrare i vantaggi - e andare da lì.

— vikingsteve
fonte

0

Dipende dalla tecnologia software (o stack) in uso (lingua interpretata, lingua compilata, app desktop, dispositivo mobile, ecc.), Software. dev. criteri del dipartimento, se disponi degli strumenti per automatizzarla, quanto è importante la tua app e una cosa importante da considerare è la tua architettura software (come è stata progettata l'app). Ecco perché qui hai risposte diverse. Come regola generale, l'approccio migliore sarà quello di ridurre il più possibile l'intervento umano nelle attività di spiegamento, per evitare errori. Una buona pratica sarà testare tutto in un QA Server (considerare l'utilizzo di un server virtuale se il budget è un problema) prima della distribuzione e avere procedure inverse per ripristinare la versione precedente in caso di disastro ( SEMPRE avere un backup).

— Edu Garcia
fonte