Come si implementa la "one step build" per un progetto LAMP?

Question

Avere il "one push build" per trasferire le modifiche dall'ambiente di sviluppo al server live è una cosa molto bella da avere e spesso sostenuta.

Sono venuto a bordo con una piccola squadra in esecuzione in uno stack LAMP e utilizzare SVN per il controllo della versione, attualmente distribuito su un singolo server di produzione (un altro server per lo sviluppo e che presto diverrà un server mysql separato). Sto solo mettendo in atto molte delle cose organizzative che mi sono mancate prima di salire a bordo.

Sono curioso di vedere

1. come le persone stanno facendo questo (un passaggio di generazione) attualmente
2. vedere come posso implementarlo meglio per la mia situazione (piccola squadra, ambiente LAMP con SVN)

Alcune sfide particolari che mi interessano sono la gestione delle modifiche al database (schema) e anche se e il tipo di "pacchetti" utilizzati dalle persone per mantenere le cose organizzate (ad esempio RPM, PEAR, ecc.).

Answer 1

Abbiamo utilizzato ant con Hudson. Ha funzionato come un fascino.

Hudson potrebbe funzionare anche con altri sistemi di compilazione e non solo con i progetti Java. Ti consente di impostare più target di build e li eseguirà automaticamente o manualmente. Ti costringe anche ad implementare un modo per eseguire la tua build da un singolo comando.

Non risolve i problemi di comunicazione in cui il server non sarà disponibile durante il tempo necessario per eseguire la compilazione per il server distribuito.

Per i nostri aggiornamenti dello schema e le modifiche, abbiamo impostato il nostro script ant di fare due cose:

1. Aggiornamento eseguito lo schema solo se c'è una differenza in SVN.
2. Archiviare un dump dello schema dopo aver creato le modifiche allo schema.
3. Se non ci fosse alcun aggiornamento allo schema, è sufficiente utilizzare la discarica per caricare un database

Lo ha fatto prendere un paio di tentativi per ottenere il diritto, ma improvvisamente ci aveva risolto il problema della più sviluppatori essere su diversi schemi . È stato così facile importare il dump per aggiornare il tuo schema di sviluppo, che potresti farlo ogni giorno.

Answer 2

Facciamo. Utilizziamo un prodotto chiamato Anthill Pro per eseguire tutte le nostre build e distribuzioni. Ha un processo del flusso di lavoro che si imposta per controllare i file, fare le build, eseguire i test delle unità e quindi distribuire il codice ai server. È possibile utilizzarlo per distribuire qualsiasi cosa in quanto il processo può eseguire programmi da riga di comando, ecc.

Answer 3

"make" su UNIX (e Windows) è tuo amico. Ha una curva di apprendimento, ma ne vale la pena. Puoi fare aggiornare l'origine, compilare, testare, ecc. Ecc.

Answer 4

Non penso che ci sia una semplice risposta a questo libro di cucina, perché questo dipende molto dal tuo ambiente. Qualunque cosa tu abbia inventato, ti consiglio caldamente un approccio basato su script, con gli script di implementazione che si trovano nel controllo del codice sorgente. Questi script consentiranno anche una migliore integrazione con le soluzioni di costruzione (vedi sotto).

Lo script più semplice da eseguire nell'ambiente di produzione sarebbe semplicemente il comando per ottenere l'ultima (o ottenere una versione specifica) dal controllo del codice sorgente.

La prossima sfida è l'implementazione del database. La soluzione che mi è piaciuta di più per i progetti di piccole e medie dimensioni è di mantenere una tabella delle versioni dello schema in ogni database e di avere tutti gli script di aggiornamento DDL e dati nel controllo del codice sorgente (incluse le origini dati che usano negli archivi compressi). Gli script sono numerati consecutivamente (a partire da 000001 ..., 000002 ..., ecc.) E lo script di distribuzione che eseguo semplicemente esegue il backup del database esistente, quindi ottiene l'ultimo script del database di esecuzione dalla tabella della versione dello schema e quindi esegue qualsiasi nuovo script di database trovato nel controllo del codice sorgente nell'ordine corretto, aggiornando di conseguenza la tabella delle versioni dello schema.

Questo approccio mi consente di ricostruire il database da zero abbastanza rapidamente.

I due approcci considerati nel loro insieme permettono di implementare rapidamente la vostra base di codice per diverse macchine di sosta diverse, l'ambiente di QA, beta, ecc

---

Per solo un po 'scenari più complessi, si dovrebbe eseguire un server di integrazione continua, come Kieveli et. al. suggerito, che essenzialmente "ricostruisce" l'intera distribuzione regolarmente e quindi contiene script per fare esattamente ciò che si dovrebbe eseguire "manualmente" sopra.

La distribuzione del database può anche essere resa più sofisticata creando uno script di rollback per ogni script di database. Dovresti quindi scrivere una piccola app per controller per gestirli. Esistono diverse soluzioni OSS per questo tipo di materiale e uno di questi potrebbe soddisfare le tue esigenze.

MA, assicuratevi di non auto-distribuire il database in un ambiente di produzione ;-)

Answer 5

strumento migliore costruzione per un progetto PHP è probabilmente Phing, che è abbastanza simile alla formica, ma è scritto in PHP. Contiene tutte le cose necessarie di cui hai bisogno per qualcosa di simile, come afferrare le cose dal tuo repository SVN.

Answer 6

Una volta completata la costruzione di una fase, è possibile trasformarla facilmente in build continue.

Abbiamo tutte le nostre build completate, contrassegnate con il numero di modifica da cui sono state create, su un server centrale. Quando qualcosa viene commesso (usiamo Perforce, ma questo funzionerebbe per SVN), un cronjob su una delle nostre caselle di compilazione nota che c'è una modifica più recente rispetto alla build, fuochi di una richiesta http per scaricare l'albero dei sorgenti e inizia a costruire (con GMake, soprattutto). Generazioni continue in pochi semplici passaggi :)

Dopodiché, è un breve passaggio per eseguire automaticamente tutta l'automazione del test. Codice completamente costruito e testato (possibilmente implementabile!) Dopo ogni commit.

Answer 7

Per il linguaggio di scripting, i soliti consigli come l'uso della variante ant-variant o CruiseControl non significano molto perché non è necessario compilare nulla.

Passiamo al database. Tre cose importanti quando si tratta di integrazione continua è automatizzare, automatizzare e automatizzare. Ciò significa che devi avere tutto, dalla creazione di database vuoti, dall'importazione da dati esterni e dall'aggiornamento alla nuova versione scriptata e pronta per l'esecuzione utilizzando alcuni script. Un buon esempio di questo potrebbe essere qualcosa come MediaWiki, che ti consente di configurare e installare utilizzando php stesso. Raccomanderei di eseguire il build server per distribuire database freschi durante il giorno, eseguire test di unità e inviare e-mail in caso di errore.

Answer 8

Il modo in cui penso di esso è che si desidera uno script per tirare tutto insieme, in pratica ottenere tutti i file \ risorse dal controllo di origine un l'eseguire tutti i passaggi per creare un 'prodotto' finale

Off the In cima alla mia testa questi passaggi potrebbero includere ottenere l'ultimo, compilare, ottenere qualsiasi altro file necessario per completare il prodotto, creare il programma di installazione (se necessario), eseguire test di unità, condividere l'output sul server (qualunque cosa ciò possa significare per un particolare progetto), e informare gli utenti che è stata creata una nuova versione (o dire se non ce l'ha, e perché). E qualsiasi altra cosa potresti aver bisogno di fare.

In passato ho iniziato di solito con una sorta di file batch, quindi ho creato un ordinatore personalizzato di tipo exe. Ma mantenere ciò è sempre diventato un dolore. Alla fine ho spostato uno su applicazioni di terze parti ... ora uso solo uno dei due prodotti di seguito.

http://www.kinook.com/VBP/

http://www.finalbuilder.com/