Qual è la tua strategia di implementazione php preferita? [chiuso]

Sto iniziando un nuovo progetto in PHP e mi piacerebbe ricevere feedback da altri sviluppatori sulla loro strategia preferita per la distribuzione di PHP. Mi piacerebbe automatizzare un po 'le cose in modo che, una volta che le modifiche sono state eseguite, possano essere migrate rapidamente su un server di sviluppo o produzione.

Ho esperienza con le distribuzioni usando Capistrano con Ruby e alcuni script di shell di base.

Prima di immergermi per la prima volta da solo sarebbe bello sentire come gli altri si sono avvicinati a questo nei loro progetti.

Ulteriori informazioni

Attualmente gli sviluppatori lavorano su installazioni locali del sito e commettono modifiche in un repository di sovversione. Le distribuzioni iniziali vengono effettuate esportando una versione taggata da svn e caricandola sul server.

Le modifiche aggiuntive vengono generalmente eseguite frammentariamente caricando manualmente i file modificati.

Per PHP, SVN con script di compilazione Phing è la strada da percorrere. Phing è simile a ANT ma è scritto in PHP, il che rende molto più semplice per gli sviluppatori PHP modificare le proprie esigenze.

La nostra routine di distribuzione è la seguente:

• Ognuno si sviluppa sullo stesso server locale al lavoro, ogni sviluppatore ha un checkout sul proprio computer anche a casa.
• I commit attivano un hook post-commit che aggiorna un server di gestione temporanea.
• I test vengono eseguiti sul server di gestione temporanea, se superano - continua.
• Lo script di compilazione di Phing viene eseguito:
• Elimina il server di produzione, cambiando il dominio in una pagina "In costruzione"
• Esegue l'aggiornamento SVN al checkout di produzione
• Esegue lo script delta dello schema
• Esegue i test
• Se i test falliscono, eseguire lo script di rollback
• Se i test vengono superati, il server torna al checkout di produzione

C'è anche phpUnderControl , che è un server di integrazione continua. Non ho trovato molto utile che i progetti web fossero onesti.

Attualmente sto implementando PHP usando Git . È sufficiente una semplice produzione git push per aggiornare il mio server di produzione con l'ultima copia di Git. È facile e veloce perché Git è abbastanza intelligente da inviare di nuovo solo le differenze e non l'intero progetto. Aiuta anche a conservare una copia ridondante del repository sul server Web in caso di guasto hardware da parte mia (anche se spingo anche su GitHub per sicurezza).

Usiamo Webistrano , un frontend web per Capistrano, e ne siamo molto contenti.

Webistrano consente implementazioni multi-stage e multi-ambiente da SVN, GIT e altri. Ha un supporto integrato per il rollback, supporto per ruoli server separati come web, db, app, ecc., E distribuisce in parallelo. Consente di sovrascrivere i parametri di configurazione su più livelli, ad esempio per fase, e registra i risultati di ogni distribuzione, opzionalmente inviandola per posta.

Anche se Capistrano e Webistrano sono applicazioni Ruby, la sintassi delle "ricette" di distribuzione è abbastanza semplice e potente da comprendere per qualsiasi programmatore PHP. Originariamente Capistrano è stato realizzato per i progetti Ruby on Rails, ma può essere facilmente utilizzato per progetti PHP.

Una volta configurato, è anche abbastanza facile da essere utilizzato da non programmatori, come i tester che distribuiscono una versione di gestione temporanea.

Per fornire la distribuzione più rapida possibile, abbiamo installato il metodo fast_remote_cache , che aggiorna una cache svn working-copy sul server remoto, quindi collega il risultato.

Uso Apache Ant per distribuire su obiettivi diversi (sviluppo, controllo qualità e live). Ant è progettato per funzionare con la distribuzione Java, ma fornisce una soluzione di caso generale piuttosto utile per la distribuzione di file arbitrari.

La sintassi del file build.xml è abbastanza facile da imparare: definisci diversi target e le loro dipendenze che vengono eseguite quando chiami il programma ant sulla riga di comando.

Ad esempio, ho obiettivi per dev, QA e live, ognuno dei quali dipende dal target cvsbuild che controlla l'ultima revisione head dal nostro server CVS, copia i file appropriati nella directory di build (usando il tag fileset) e quindi sincronizza la directory di build con il server appropriato. Ci sono alcune stranezze da imparare e la curva di apprendimento non è del tutto piatta, ma lo sto facendo da anni senza problemi, quindi lo consiglierei per la tua situazione, anche se sono curioso di sapere quali altre risposte vedremo su questa discussione.

Faccio le cose manualmente usando Git. Un repository per lo sviluppo, che viene git push --mirrorportato a un repository pubblico, e il server live è un terzo repository estratto da quello. Questa parte suppongo sia la stessa della tua configurazione.

La grande differenza è che uso i rami per quasi tutti i cambiamenti a cui sto lavorando (ne ho circa 5 in questo momento) e tendo a spostarmi avanti e indietro tra di loro. Il ramo principale non viene modificato direttamente tranne che per l'unione di altri rami.

Eseguo il server live direttamente dal ramo master e quando ho finito con un altro ramo e pronto a unirlo, capovolgo il server su quel ramo per un po '. Se si rompe, rimetterlo al master richiede pochi secondi. Se funziona, viene unito in master e il codice live viene aggiornato. Suppongo che un'analogia di questo in SVN sarebbe avere due copie funzionanti e indicare quella live tramite un collegamento simbolico.

So che Phing è stato menzionato alcune volte, ma ho avuto molta fortuna con phpUnderControl . Per noi noi

1. Controlla le singole copie delle filiali su macchine locali
2. I rami vengono testati e quindi uniti in Trunk
3. Gli commit su Trunk vengono creati automaticamente da phpUnderControl, esegue test e crea tutta la documentazione, applica i delta del database
4. Trunk viene sottoposto a test di qualità e quindi unito al nostro ramo Stable
5. Ancora una volta, phpUnderControl crea automaticamente Stable, esegue test e genera documentazione e aggiorna il database
6. Quando siamo pronti per passare alla produzione, eseguiamo uno script rsync che esegue il backup di Production, aggiorna il database e quindi esegue il backup dei file. Il comando rsync viene invocato a mano in modo da assicurarci che qualcuno stia guardando la promozione.

un'alternativa agli script di distribuzione fatti in casa è quella di distribuire su una piattaforma come servizio che consente di estrarre gran parte di quel lavoro per te. Un PaaS offre in genere il proprio strumento di distribuzione del codice, nonché il ridimensionamento, la tolleranza agli errori (ad es. Non si arresta in caso di guasto dell'hardware) e di solito un ottimo kit di strumenti per il monitoraggio, il controllo dei registri, ecc. C'è anche il vantaggio di distribuire in un una buona configurazione nota che verrà mantenuta aggiornata nel tempo (un mal di testa in meno per te).

Il PaaS che consiglierei è dotCloud , oltre a PHP ( vedi il loro avvio rapido PHP ) può anche distribuire MySQL, MongoDB e un sacco di servizi aggiuntivi. Ha anche dei buoni extra come l'implementazione a zero downtime, il rollback istantaneo, il pieno supporto per SSL e websocket, ecc. E c'è un livello gratuito che è sempre bello :)

Ovviamente sono un po 'di parte dal momento che ci lavoro! Altre opzioni che vale la pena provare oltre a dotCloud sono Pagodabox e Orchestra (ora parte di Engine Yard).

Spero che questo ti aiuti!

Salomone

Il fatto di apportare automaticamente e ciecamente le modifiche da un repository ai server di produzione sembra pericoloso. Cosa succede se il codice commesso contiene un bug di regressione, quindi l'applicazione di produzione diventa glitch?

Ma, se vuoi un sistema di integrazione continua per PHP, immagino che Phing sia la scelta migliore per PHP. Non l'ho provato io stesso, tuttavia, poiché eseguo il rooting nel modo manuale di es. Scp.

Sono in ritardo alla festa, ma ho pensato di condividere i nostri metodi. Usiamo Phing con Phingistrano , che fornisce funzionalità simili a Capistrano a Phing tramite file di build predefiniti. È molto bello, ma funziona solo se usi Git al momento.

Ho una copia funzionante di un ramo di rilascio SVN sul server. L'aggiornamento del sito (quando non ci sono modifiche allo schema) è facile come emettere un comando di aggiornamento SVN. Non devo nemmeno portare il sito offline.

Phing è probabilmente la soluzione migliore, se riesci a sopportare il dolore dei file di configurazione XML. Il framework Symfony ha il suo port of rake (pake), che funziona abbastanza bene, ma è piuttosto strettamente accoppiato al resto di Symfony (anche se probabilmente potresti separarli).

Un'altra opzione è utilizzare Capistrano. Ovviamente non si integra altrettanto bene con PHP, come fa con Ruby, ma puoi comunque usarlo per molte cose.

Infine, puoi sempre scrivere script di shell. Finora, è quello che ho fatto.

http://controltier.org/wiki/Main_Page

lo useremo per distribuzioni e manutenzione multi-server.

Un anno di ritardo ma ... Nel mio caso, la distribuzione non è automatica. Trovo pericoloso distribuire codice ed eseguire automaticamente script di migrazione del database.

Al contrario, gli hook di sovversione vengono utilizzati per distribuire solo al server di test / gestione temporanea. Il codice viene distribuito alla produzione al termine di un'iterazione, dopo aver eseguito i test e verificato che le cose funzionino. Per la distribuzione stessa, utilizzo un Makefile su misura che utilizza rsync per il trasferimento di file. Il Makefile può anche eseguire gli script di migrazione sul server remoto, mettere in pausa / riprendere server Web e database.

Nel mio lavoro, io e il mio team abbiamo sviluppato un sostituto orientato a Phing per la distribuzione di capistrano e abbiamo anche incorporato alcune delle chicche disponibili nel phing come test PHPUnit, phpcs e PHPDocumentor. Abbiamo creato un repository git che può essere aggiunto a un progetto come sottomodulo in git e funziona molto bene. L'ho collegato a una manciata di progetti ed è abbastanza modulare che è facile farlo funzionare con qualsiasi progetto in uno dei nostri diversi ambienti (messa in scena, test, produzione, ecc ...).

Con gli script di build phing puoi eseguirli manualmente dalla riga di comando e ho anche avuto successo nell'automazione delle routine di build / deploy con Hudson e ora Jenkins ci.

Non posso pubblicare alcun link ora perché il repository non è ancora pubblico, ma mi è stato detto che lo apriremo a volte presto, quindi non esitate a contattarmi se siete interessati o se avete eventuali domande sull'automazione della distribuzione con phing e git.

Immagino che il modo di schieramento SVN non sia molto buono. Perché:

Devi aprire l'accesso SVN per tutto il mondo

avere molti .svn nei server Web di produzione

Penso che Phing per produrre un ramo + combinare tutti i js / css + sostituire stage config + ssh upload su tutti i server www sia il modo migliore.

ssh to 10 www server e svn up è anche un problema.