Come trasferire file in produzione?

Siamo un gruppo che ha iniziato a lavorare su un sito Web abbastanza grande con una base di codice esistente. Abbiamo un test e un server di produzione.

La nostra idea è di avere un repository di prova con un numero di sviluppatori che hanno accesso push; e un deposito benedetto a cui solo pochi possono spingere. Il repository benedetto dovrebbe essere sempre stabile e rappresentare l'ultima versione di produzione.

Come posso automatizzare il processo di trasferimento dei file in produzione? È male avere i file di produzione sotto il controllo della versione? In questo modo, spingendo verso l'archivio benedetto significherebbe dispiegamento. Ma cosa succede quando ci sono conflitti di unione? Il server di produzione si romperà fino a quando non verrà risolto?

Per dirla in parole semplici:
il processo push in sé dovrebbe essere completamente automatico. Sia che tu abbia uno script personalizzato o semplicemente passi dal repository "benedetto" all'ambiente di produzione. Questo dipende da te. Dovresti semplicemente avere qualcosa di automatizzato, perché i processi automatizzati possono essere resi affidabili (al contrario del caricamento manuale dei file e simili).

Tuttavia, il processo push deve essere attivato manualmente. Spingi i tuoi aggiornamenti e, una volta che ti senti sicuro, lo tagghi come candidato di rilascio e lo trascini nel tuo ambiente di test (sarebbe idealmente il più simile possibile al tuo ambiente di produzione). Una volta testato l'RC, è possibile avviare la spinta.
Ad oggi, nient'altro può darti, cosa possono fare i tester umani.

Sembra un po 'lento, nel senso che il circuito di feedback è relativamente grande. Ma per test adeguati, è importante fare un'istantanea fissa, che viene quindi esaminata per 24-48 ore (o forse di più, a seconda delle dimensioni del progetto). L'opposto è uno scenario in cui si trovano molti bug subito dopo aver premuto e si tenta di correggerlo con alcune correzioni rapide che introducono nuovi bug.
È meglio effettuare un rilascio con bug noti (di gravità accettabile), piuttosto che con bug sconosciuti (di gravità sconosciuta).

Ho imparato molto sull'implementazione osservando come funziona Capistrano. All'epoca lavoravo con RoR, quindi era una scelta logica e sebbene non mi fossi mai comportato bene per il progetto su cui stavo lavorando, il modo in cui esegue gli aggiornamenti automatici è stato molto utile.

Potresti trovarti in una situazione in cui puoi usarlo direttamente anche - non è necessariamente legato a Rails - ma in caso contrario, il modo in cui si comporta è sicuramente utile.

A seconda della piattaforma che stai utilizzando, ci sono molti strumenti là fuori che potrebbero avere senso usare per automatizzare le versioni di produzione. Lavoro in un negozio .NET, quindi abbiamo usato NAnt (sebbene MSBuild sia un'opzione migliore al giorno d'oggi). Java ha Ant, e forse altre cose. Ruby ha cose come Rake. Esistono poi piattaforme di integrazione continua come TeamCity e Hudson che possono essere utilizzate anche per la gestione delle versioni.

Non ho mai visto o sentito parlare di avere il codice prod direttamente in un repository di controllo del codice sorgente separato, ma potrebbe sicuramente funzionare. Come detto back2dos, la chiave è automatizzare. Abbiamo i nostri script di build progettati per estrarre dal controllo del codice sorgente, compilare e spingere nell'ambiente di gestione temporanea per i test. Quindi, quando ci piace come funziona la stadiazione, gli script vengono copiati dal QA a Prod.

La mia raccomandazione è di guardare gli strumenti là fuori e sceglierne uno, quindi progettare un processo che funzionerà bene con lo strumento selezionato. Non cercare di reinventare troppo la ruota: questo è un problema molto risolto.