Implementazione del progetto PHP

2

Ho un progetto PHP che sto attualmente sviluppando.

Ho quasi finito e mi stavo chiedendo quale sia la migliore pratica in termini di beta test e distribuzione di aggiornamenti / modifiche al sito di produzione?

Ad esempio, per testare nuove funzionalità, ho pensato di creare un sottodominio chiamato beta.mysite.com che utilizza una duplicazione degli stessi file di progetto della versione di produzione e una duplicazione del mysql db.

Poi dopo aver provato tutto, ho bisogno di esportare le tabelle mysql (se ho cambiato la struttura db) e copiare i file nell'area di produzione.

Ma come faccio a fare tutto ciò mantenendo tutti i dati che sono stati prodotti durante il mio beta test?

Sono l'unica persona che lavora su questo progetto, attualmente non uso alcun strumento di versioning, solo Dreamweaver.

Grazie,

    
posta Or W 28.03.2011 - 14:39
fonte

4 risposte

3

Consiglio vivamente di implementare un VCS per te. Anche se sei l'unico sviluppatore, è un ottimo strumento da avere. Sarai in grado di distribuire il codice più facilmente, annullare gli errori in un istante e tracciare l'evoluzione delle modifiche al codice. Per questo, ho trovato Mercurial un ottimo strumento da usare data la sua configurazione veloce e la sua semplicità generale, tuttavia sentitevi liberi di usare qualsiasi che ti piace (git, SVN, ecc.).

Per quanto riguarda la distribuzione con un VCS, puoi creare tag per varie versioni nella tua base di codice e lavorare su più versioni contemporaneamente (beta per 2.0, dev per 3.0, ecc.). Quindi, distribuire il codice dalla beta 2.0 diventa questione di eseguire un singolo comando.

Per la sincronizzazione del database, ho trovato DB Deploy essere molto utile per l'aggiornamento del mio database al più tardi rispetto all'attuale codice base richiede. Questo è utile per aggiornare il database dell'ambiente di test anche alla configurazione appropriata. Utilizzando questo strumento, puoi apportare tutte le modifiche richieste con un singolo comando.

    
risposta data 28.03.2011 - 20:08
fonte
0

Se capisco la tua domanda, sembra che dovrai creare uno script per alterare le tabelle SQL esistenti nell'area di produzione, piuttosto che semplicemente sostituirle. Controlla la sintassi della tabella degli errori di MySQL . (Se ho frainteso la tua domanda, ti preghiamo di chiarire.)

Inoltre, penso che sia preferibile avere l'area di sviluppo su una macchina separata, magari su una VM locale.

    
risposta data 28.03.2011 - 17:40
fonte
0

Come già accennato, è necessario esaminare gli script di alterazione. È possibile apportare modifiche alle tabelle sul sito live manualmente se non ci sono molte modifiche. Ma seguendo questo se i dati devono essere manipolati per adattarsi alle nuove tabelle, in genere è possibile programmare un programma php veloce in grado di scorrere le tabelle per apportare tutte le modifiche. (Anche in questo caso, se la dimensione dei dati non è ampia, potresti essere in grado di apportare queste modifiche più rapidamente manualmente in alcuni casi altrimenti questo è l'approccio che consiglierei.)

Inoltre, posso dire per esperienza quando dico che la tua idea iniziale di avere un sottodominio sullo stesso server è la migliore opzione per testare. Altrimenti rischi di avere configurazioni diverse che possono realmente causare mal di testa MAJOR al momento del deployment. In qualche sviluppo non sei in grado di farlo sempre, ma se puoi, lo consiglio vivamente. Oltre a questo, dovresti impostare le tue esigenze di implementazione.

    
risposta data 28.03.2011 - 19:38
fonte
0

Hai esaminato strumenti come PHPUnderControl, Phing, Ant, ecc.? Automatizzeranno molto il lavoro di implementazione per te.

In alternativa, crea semplicemente il tuo script Bash che crea una versione di produzione del codice e rsyncs o SFTP sul server di produzione. L'automazione è buona perché ti impedisce di dimenticare di fare qualcosa quando devi aggiornare il sito in futuro.

Immediatamente dopo averlo messo sul server di produzione, esegui test Selenium sull'app per assicurarti che nulla sia sbagliato. È qui che il controllo della versione è ottimo: se c'è un problema, devi semplicemente eseguire lo script di build su una versione precedente e il problema è contenuto.

    
risposta data 14.04.2011 - 21:16
fonte

Leggi altre domande sui tag