PHP Site Deployment Suggerimento [chiusa]

Question

Attualmente sto abbastanza turbato per la via della distribuzione mia squadra sta adottando ... E 'molto vecchio stile e so che non funziona molto bene. Ma io non so esattamente come cambiarlo, quindi per favore dare qualche suggerimento su di esso ...

Qui è la nostra messa a punto corrente:

• 2 server web
• 1 server di database
• 1 server di test

attuale adeguamento distribuzione

1. Sviluppiamo e il lavoro sul server di prova, ogni modifica viene caricato manualmente al server di prova.
2. Quando un cambiamento o una funzione è completa, abbiamo poi le modifiche al repository SVN.
3. Dopo aver commesso i cambiamenti, abbiamo poi caricare le nostre modifiche al primo server web, dove ci sarà un cronjob esecuzione ogni minuto per sincronizzare i file tra i server.

Una cosa molto fastidiosa è, ogni volta che caricare un file proprio come inizia il lavoro di sincronizzazione, il file che è sync-ed apparirà corrotto, dal momento che è solo a metà caricato. Un'altra cosa è ogni volta che v'è un guasto distribuzione, sarà estremamente difficile da ripristinare. Queste sono fondamentalmente il problema che sto affrontando, cosa devo fare?

In aggiunta, dal momento che ci sono file al 1 ° server web che deve essere sincronizzazione ed al altri server in qualsiasi momento, in modo che il cronjob era lì per la ragione.

P / S: Mi Mi dispiace dimenticato di dire che, il server SVN è ospitato. Non abbiamo troppo controllo su di esso, ma credo di poter modificare ganci ...

Answer 1

Usa un quadro di distribuzione come Phing per gestire distribuzione per i server web e sbarazzarsi del lavoro cron. In sostanza, un comunicato sul sistema di produzione non dovrebbe accadere automaticamente, ma solo dopo che si è certi della generazione corrente non è rotto. E non dovrebbe avere una dipendenza dal sistema dev.

Dal Phing utilizza XML e PHP per configurare e controllare il processo di distribuzione, è possibile controllare il processo di versione. Questo è un ulteriore vantaggio, come si può quindi mantenere la distribuzione collegato a specifiche build dell'applicazione.

Per evitare che il sito di produzione da essere colpiti dal processo di distribuzione, si consideri il caricamento di una nuova build in una directory separata e poi basta link simbolico ad esso. Se qualcosa va storto, si può facilmente collegamento simbolico ad una versione precedente.

utilizzando un server CI .

Answer 2

Ho fatto la stessa cosa al mio ultimo posto. Ciò che abbiamo avuto è stato:

• un repository per ogni sito web
• un ramo per ogni sito web dedicato al sito live (cioè /branches/live) e sito di prova (cioè /branches/testing)
• 2 server web, che poteva parlare con SVN
• un server di prova che potrebbe parlare con SVN
• tutti i server aveva SVN client a riga di comando installato

Ogni server web gestione indipendente, in modo che in realtà non conoscono l'un l'altro - che è stato lasciato al bilanciamento del carico. Ogni server aveva un cronjob che correva ogni 3 ore e esportato l'ultima versione del ramo live di ogni sito web nella cartella corretta nel file system.

Sul nostro server di prova, è stato un checkout del ramo testing per ogni sito web, e non cronjob. Gli sviluppatori aggiornate le cartelle ogni volta che volevano mettere qualcosa per gli utenti di prova prima che è andato in diretta.

Nel corso sviluppi, sono state fatte commit al trunk del sito. Quando i cambiamenti erano pronti per i test, sono stati uniti nel ramo testing e alla cassa aggiornato manualmente sul server di prova. Quando i cambiamenti erano pronti per andare a vivere, sono state fuse al ramo vivo e gli assistenti avrebbero aggiornato entro la fine della giornata.

In 3 anni abbiamo avuto solo un problema in cui uno sviluppatore aveva commesso qualcosa di sbagliato e ha dovuto rotolare il sito di nuovo.

Answer 3

Come una correzione parziale, creare un URL del sito web che fa scattare il comando rsync quando si visita, in modo che è possibile controllare quando viene eseguito rsync (ovviamente, è necessario assicurarsi di server di colpo 1 con questo URL e non esporre l'URL al pubblico). Meglio ancora, l'uso curl per richiamare l'URL rsync alla fine di qualsiasi script di upload si utilizza.