migliorare la nostra strategia di implementazione

Abbiamo un'app di e-commerce che sviluppiamo presso la nostra azienda. È un'applicazione LAMP ragionevolmente standard che stiamo sviluppando dentro e fuori da circa 3 anni. Sviluppiamo l'applicazione su un dominio di prova, qui aggiungiamo nuove funzionalità e correggiamo i bug, ecc. Il nostro monitoraggio dei bug e lo sviluppo delle funzionalità sono tutti gestiti all'interno di una soluzione di sovversione ospitata (unfuddle.com). Man mano che vengono segnalati dei bug, apportiamo queste correzioni al dominio di test e quindi eseguiamo le modifiche su svn quando siamo felici che il bug sia stato corretto. Seguiamo questa stessa procedura con l'aggiunta di nuove funzionalità.

Vale la pena sottolineare lì l'architettura generale del nostro sistema e delle applicazioni sui nostri server. Ogni volta che viene sviluppata una nuova funzionalità, questo aggiornamento viene distribuito a tutti i siti utilizzando la nostra applicazione (sempre un server che controlliamo). Ogni sito che utilizza il nostro sistema utilizza essenzialmente esattamente gli stessi file per il 95% della base di codice. Abbiamo un paio di cartelle all'interno di ogni sito che contengono file personalizzati per quel sito - file CSS / immagini ecc. Oltre a ciò, le differenze tra ciascun sito sono definite da varie impostazioni di configurazione all'interno di ciascun database dei siti.

Questo accede alla distribuzione vera e propria. Come e quando siamo pronti a distribuire un aggiornamento di qualche tipo, eseguiamo un comando sul server su cui si trova il sito di test. Questo esegue un comando di copia (cp -fru / testsite / / othersite /) e passa attraverso ogni forza vhost aggiornando i file in base alla data modificata. Ogni server aggiuntivo su cui ospitiamo ha un vhost a cui sincronizziamo la base di codice di produzione e quindi ripetiamo la procedura di copia su tutti i siti su quel server. Durante questo processo spostiamo i file che non vogliamo sovrascrivere, spostandoli indietro una volta completata la copia. Il nostro script di rollout svolge una serie di altre funzioni come l'applicazione di comandi SQL per modificare ciascun database, l'aggiunta di campi / nuove tabelle ecc.

Ci siamo sempre più preoccupati del fatto che il nostro processo non è abbastanza stabile, non tollerante ai guasti ed è anche un po 'un metodo a forza bruta. Siamo anche consapevoli che non stiamo sfruttando al meglio la sovversione poiché abbiamo una posizione in cui lavorare su una nuova funzionalità ci impedirebbe di implementare una correzione di bug importante poiché non stiamo facendo uso di rami o tag. Sembra anche sbagliato che abbiamo così tanta replica dei file sui nostri server. Inoltre, non siamo in grado di eseguire facilmente un rollback su ciò che abbiamo appena implementato. Effettuiamo un diff prima di ogni lancio in modo da poter ottenere un elenco di file che verranno modificati in modo da sapere cosa è stato modificato dopo ma il processo di rollback sarebbe ancora problematico. In termini di database ho iniziato a esaminare dbdeploy come una potenziale soluzione. Ciò che vogliamo veramente è però una guida generale su come possiamo migliorare la nostra gestione e distribuzione dei file. Idealmente, vogliamo che la gestione dei file sia più strettamente collegata al nostro repository, in modo che un rollout / rollback sia più connesso a svn. Qualcosa come usare il comando export per assicurarsi che i file del sito siano gli stessi dei file repo. Sarebbe anche positivo se la soluzione potesse anche arrestare la replica dei file sui nostri server.

Ignorando i nostri metodi attuali sarebbe davvero bello sentire come le altre persone affrontano lo stesso problema.

riassumere ...

• Qual è il modo migliore per far sincronizzare i file su più server con svn?
• Come dovremmo impedire la replica dei file? symlink / qualcos'altro?
• Come dovremmo strutturare il nostro repository in modo da poter sviluppare nuove funzionalità e correggere quelle vecchie?
• Come dovremmo attivare i rollout / rollback?

Grazie in anticipo

MODIFICARE:

Di recente ho letto molte cose positive sull'uso di Phing e Capistrano per questo tipo di attività. Qualcuno può fornire ulteriori informazioni su di loro e quanto sarebbe bello per questo tipo di attività?

Il mio consiglio per fare rilasci è avere rilasci di funzioni e rilasci di manutenzione. Rilasci di funzionalità sarebbero le versioni che ottengono nuove funzionalità. Questi vengono aggiunti al tuo trunk sovversione. Quando si ritiene che queste siano complete, le si ramificano in un ramo di rilascio. Una volta che il processo di QA è soddisfatto di questa versione, è possibile taggare la versione e distribuire il codice sui server.

Ora, quando ricevi una segnalazione di bug, commetti questa correzione sul ramo e la porti sul trunk. Quando sei soddisfatto del numero di bug corretti, puoi taggare e distribuire una versione di manutenzione.

È importante disporre di un ramo della base di codice in tempo reale (o avere la possibilità di crearne uno conoscendo la revisione in tempo reale) che sia separato dal ramo di sviluppo, in modo da avere la possibilità di distribuire correzioni al codice in tempo reale senza dover distribuire nuove funzionalità o codice non testato.

Consiglierei di utilizzare il sistema di packaging nativo della tua distribuzione per distribuire un nuovo codice. Se hai un pacchetto che contiene tutta la tua base di codice, sai che tutto il tuo codice è stato distribuito in una sorta di operazione atomica, puoi vedere a colpo d'occhio quale versione è installata, puoi verificare la tua base di codice usando il checksum dei pacchetti. Il rollback è solo un caso di installazione della versione precedentemente installata del pacchetto.

L'unico ostacolo che posso vedere per te implementare questo è che sembra che tu abbia più copie della base di codice per diversi clienti in esecuzione su un singolo server. Tenterei di organizzare il codice in modo che tutti i clienti eseguano gli stessi file e non utilizzino le copie. Non so quanto sarebbe facile per te, ma ridurre il numero di copie che dovrai gestire ridurrà enormemente il tuo mal di testa.

Suppongo che, come hai detto LAMP, stai usando PHP o un altro linguaggio di scripting, che non richiede un processo di compilazione. Ciò significa che probabilmente ti stai perdendo un meraviglioso processo chiamato Integrazione continua. Ciò significa sostanzialmente che il codice viene continuamente testato per assicurarsi che sia ancora in uno stato rilasciabile. Ogni volta che qualcuno controlla un nuovo codice, un processo lo prende ed esegue il processo di compilazione e test. Con un linguaggio compilato di solito lo utilizzeresti per assicurarti che il codice sia ancora compilato. Con ogni lingua dovresti cogliere l'occasione per eseguire unit test (il tuo codice è in unità testabili non è vero?) E test di integrazione. Per i siti Web, un buon strumento per testare i test di integrazione è il selenio. Nelle nostre build Java, misuriamo anche la copertura del codice e le metriche del codice per vedere come progrediamo nel tempo. Il miglior server CI che abbiamo trovato per Java è Hudson, ma qualcosa come buildbot potrebbe funzionare meglio per altre lingue. Puoi creare pacchetti usando il tuo server CI.

Abbiamo iniziato a utilizzare Puppet (prodotto di punta di Reductive Labs). È un framework basato su Ruby per l'automazione dei lavori sys-admin. Sono stato al puppetcamp un paio di settimane fa e qui ci sono i collegamenti video:

Presentazione di Luke Kanies - Introduzione alle marionette

Inoltre, se desideri vedere tutte le presentazioni fatte al puppetcamp di san francisco, questo è il link:

Presentazioni su come gli altri hanno usato Puppet

Godere.