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


161

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.


Carino :) Grazie per la modifica splattne.
GloryFish,

1
@ Paul Tomblin: OMG, non riesco a smettere di ridere !!!!! Non c'è modo migliore :)
Andrei Rînea,

Qualcuno può rispondere questo per favore - stackoverflow.com/questions/36034277/...
Sandeepan Nath

Risposte:


109

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.


Stavo per pubblicare un elenco di ciò che faccio nel mio negozio Windows / .NET, ma è più o meno quello che hai qui. +1
Daniel Schaffer,

hai riscontrato degli svantaggi per avere un svn co come ambiente di produzione? Davvero non riesco a pensare ad alcuno svantaggio ma non sembra "pulito" avere un svn co come produzione? Perché non un'esportazione svn o rsync?
ChrisR,

A causa della differenza di base tra un co ed un'esportazione: non è possibile inviare modifiche specifiche, è necessario esportare nuovamente l'intera applicazione. È una differenza molto importante che rende la vita molto più semplice
Eran Galperin,

36
Perché mettere il sito sullo schermo in basso? Se esegui una directory di rilasci / e punta liveSite / tramite un link simbolico alla tua cartella in rilasci /, allora puoi completare il checkout del sito in una nuova versione / cartella e capovolgere il link simbolico istantaneamente una volta fatto il co? Non sono necessari tempi di inattività (a meno che tu non sia il povero singhiozzo che fa una richiesta durante quel passaggio di collegamento simbolico).
Joseph Lust,

2
Chi è responsabile di tutte quelle attività come l'aggiornamento SVN sulla produzione e il collegamento simbolico nella nuova versione? Phing? È jenkins?
Daniel Ribeiro,

24

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).


Ho fatto la stessa cosa per anni anche su progetti di piccole e medie dimensioni. Devo dire che ha funzionato benissimo per me. Devi amare la semplicità di questo approccio.
Chris Allen Lane,

3
Come gestite il database con questo approccio?
32423hjh32423,

1
@neilc A mano, sfortunatamente. Qualsiasi modifica al DB deve essere eseguita manualmente prima del push.
Kyle Cronin,

Di solito includo () un file PHP che contiene la configurazione del DB e posiziono manualmente il file sul server o sulla macchina di prova. In questo modo non stai memorizzando le password in git e non operando accidentalmente su un database di produzione.
Matt,

Come si configura git per farlo per te? C'è qualche guida / tutorial? Grazie in anticipo.
Miguel Stevens,

14

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.


7

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.


6

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.


3

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.

5
phpUnderControl è morto: |
m02ph3u5,

3

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


2

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.


2

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.


1

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.


1
quindi hai directory .svn sparse in tutto il sito? il mio cervello purista va contro questo :)
Stann

Questo si occupa solo del codice sorgente. Le implementazioni richiedono spesso altre azioni: modifiche del database applicate, cache cancellate, ecc.
Leonid Mamchenkov,

1

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.



1

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.


1

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.


0

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.


Aprire il mio server svn a tutto il mondo, assolutamente no! Basta usare il firewall e l'autenticazione su SSL per limitare chi può vedere il tuo codice.
Shadok,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.