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

https://stackoverflow.com/questions/425692

06-07-2019
|

Domanda

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 in genere apportate frammentariamente caricando manualmente i file modificati.

Soluzione

Per PHP, SVN con Phing sono gli script per costruire. Phing è simile a ANT ma è scritto in PHP, il che rende molto più facile per gli sviluppatori PHP modificare i propri ha bisogno.

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 un " In costruzione " Pagina
Esegue l'aggiornamento SVN al checkout di produzione
Esegue lo script delta dello schema
Esegue i test
Se i test falliscono - esegui 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.

Altri suggerimenti

Attualmente sto implementando PHP utilizzando 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 soddisfatti.

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 creato per i progetti Ruby on Rails, ma può essere facilmente utilizzato per progetti PHP.

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

Per fornire la distribuzione più veloce possibile abbiamo installato il metodo fast_remote_cache , che aggiorna un svn working-copy cache sul server remoto e quindi hardlink il risultato.

Uso Apache Ant per distribuire su diversi target (sviluppo, QA 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 della testa dal nostro server CVS, copia i file appropriati nella directory di compilazione (usando il tag fileset) e quindi sincronizza nuovamente la directory di generazione sul 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 cose manualmente usando Git. Un repository per lo sviluppo, che ottiene git push --mirror 'su 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 principale 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 ora, ma ho avuto molta fortuna con < a href = "http://www.phpundercontrol.org/about.html" rel = "nofollow noreferrer"> phpUnderControl . Per noi

Guarda le singole copie delle filiali su macchine locali
I rami vengono testati e quindi uniti in Trunk
Gli commit su Trunk vengono creati automaticamente da phpUnderControl, esegue test e crea tutta la documentazione, applica i delta del database
Trunk viene sottoposto a test di qualità e quindi unito al nostro ramo Stable
Ancora una volta, phpUnderControl crea automaticamente Stable, esegue test e genera database di documentazione e aggiornamenti
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 toglie 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 la loro guida rapida 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 aiuti!

Solomon

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 roba nel modo manuale di ad 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 è usare 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 multi-server & amp; manutenzione.

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

Invece, gli hook di sovversione vengono usati per distribuire solo al server di test / staging. 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 l'implementazione 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 su 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 compilazione / distribuzione 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 in caso di 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

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

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow