Il processo di solito viene gestito attorno a un repository di controllo di origine (SVN nel mio caso), il che rende le cose molto più semplici (o possibili, davvero ...). L'idea è di mantenere tutto il possibile nel repository e utilizzare gli aggiornamenti e i tag SVN per pubblicare le modifiche.
local.xml: mi muovo questo file in SVN per local.xml.dist e ignorare il file vero e proprio local.xml nel repository. Ciò consente di utilizzare credenziali di database e host diversi nelle installazioni senza inquinare il codebase.
altro ignora: Partenza this question per più file che devono essere ignorati nel database. Fondamentalmente, qualsiasi cosa unica per l'ambiente dovrebbe essere mantenuta fuori dal controllo della versione e gestita dall'host reale. I tuoi file .htaccess saranno rilevanti qui.
impostazione host: il mio ambiente di staging e gli ambienti di sviluppo sono impostati per essere eseguiti fuori/trunk dal repository. Lo sviluppo avviene qui e può essere spinto periodicamente (o su richiesta) via svn up per mostrare nuove funzionalità al client e fare UAT. L'ambiente di produzione ha bisogno di una protezione dal Wild West del trunk, tuttavia, in modo che l'ambiente scenda dai tag. Ogni volta che un set di funzioni è pronto per uscire, creo un nuovo tag dal trunk e faccio un svn switch per passare al nuovo set di codici. Fare le cose in questo modo mi dà anche un facile annullamento per la produzione (tornare all'ultima tag). Così ho rimosso tutte le spinte di file manuali dalla mia vita, il che è positivo.
Un sistema ancora migliore (che non avevo ancora bisogno) sarebbe quello di utilizzareper creare una copia completa dell'albero del codice sul sistema di produzione e utilizzare ln per passare da uno all'altro. Qualcosa del genere:
> cd /home/apacheuser
> ls -l
www -> /home/apacheuser/tag_1.0.1
tag_1.0.1
> svn export /url/for/repo/tags/1.0.2 tag_1.0.2
... svn exports here ...
> rm www; ln -s /home/apacheuser/tag_1.0.2 www
In questo modo, le modifiche di versione sono istantanee.
db sincronizzazione indietro dalla produzione: per permettere a me di lavorare su dati di produzione-ish, ho un cron-job impostato per eseguire il dump del database di produzione e importarlo in messa in scena. Mentre ciò accade, lo script rimuoverà i dati sensibili dei clienti (e cambierà gli indirizzi email dei clienti in modo che tutte le email vengano indirizzate a me). Inoltre, modificherà le impostazioni del gateway della carta di credito in un gateway di prova e modificherà i parametri base_url in modo che gli URL del sito di staging funzionino correttamente.
nuovo sviluppo: Si può notare qui che gli ambienti diversi scappare di circa la stessa base di codice (al netto di eventuali nuovi cambiamenti), che può sembrare fastidioso per voi da quello che hai notato cambiamenti di database, ecc
L'unico modo per gestire questa complessità (e nel modo giusto, allo stesso tempo!) È assicurarsi che il codice stesso tenga traccia delle modifiche necessarie all'ambiente. Magento supporta automatico aggiornamenti di versione del modulo, inclusi gli script di database, che si dovrebbe utilizzare per apportare modifiche allo schema, ecc Questo significa che, come si distribuisce il nuovo codice di attivazione/la produzione (o come si ottiene da un altro sviluppatore nel vostro ambiente dev), tutte le patch del database vengono applicate automaticamente.
Ciò significa anche che è necessario scrivere nuove funzionalità per essere il più possibile non distruttive. I temi Magento, i moduli disabilitati e simili possono essere utilizzati per rendere questo una realtà. Ad esempio, quando si crea un nuovo tema per il sito, assicurarsi di non modificare alcuno dei comportamenti di base e mantenere tutte le nuove risorse in un tema che sarà inattivo sulla produzione fino al momento della distribuzione.
altri sviluppatori: questa configurazione si basa su un numero relativamente piccolo di sviluppatori su un progetto. Vi è un'ipotesi implicita che, quando si desidera taggare una nuova versione, è possibile ottenere il trunk in uno stato funzionante per farlo. Con più sviluppatori, questo sarà sempre meno il caso, quindi è necessaria una più complessa configurazione dei pronti contro termine. Se mi imbatto in questo, il mio piano è quello di passare a utilizzare git al posto di SVN e utilizzare i rami di funzionalità per un nuovo sviluppo.
fatemi sapere se nulla di tutto ciò era poco chiaro. Spero possa aiutare!
Grazie, Joe
Sono interessato a questo anche. Il mio lavoro principale è il mantenimento di un negozio di e-commerce basato su .NET, dove usiamo Windows Installer per distribuire gli aggiornamenti in modo controllato, ei progetti di lato di Magento sono un po 'nuovi e ci sentiamo un po' avventati quando si tratta di distribuzione! Penso che uno di questi giorni, dovrò costruire un grande script bash per gestire il processo di aggiornamento. –