33

I am looking setting up a deployment process for a highly customized Magento site, and was wondering how other people do this.

I will be setting up dev, UAT and prod environments. All the Magento files will be in source control (SVN). At this stage, I can't see any requirements for changing the DB, so the 3 databases will be manually maintained.

Specifically,

  • How do you apply Magento upgrades? (Individually in each env, or on dev then roll out, or just give up on upgrades?)
  • What files/folders do leave alone in each environment (e.g. magento/app/etc/local.xml)
  • Do you restrict developers to editing specific files/folders?
  • Do you restrict theme designers to editing specific files/folders?
  • How do you manage database changes?

Theme Designer Files/Folders

Designers can restricted to editing the following folders-

app/design/frontend/your_interface/your_theme/layout/
app/design/frontend/your_interface/your_theme/template/
app/design/frontend/your_interface/your_theme/locale/
skin/frontend/your_interface/your_theme/

Extension Developer Files/Folders

Extension developers can edit the following folders/files-

/app/code/local
/app/etc/modules/<Namespace>_<Module>.xml

Database environment management

As the store's base URL is stored in the database, you cannot just copy databases between environments. Options include-

khellang
  • 17,550
  • 6
  • 64
  • 84
Spongeboy
  • 2,232
  • 3
  • 28
  • 37
  • You might want to remove "best answer" from below, as it doesn't even answer your main points. – Oddman Apr 28 '13 at 22:26
  • Fair point. I think that answer makes a great point, but happy for the voting to decide on prominence of answers. – Spongeboy May 02 '13 at 02:27
  • No worries - I just figure the answer that actually answers the question, is the one that should be "best answer", regardless of votes. If an answer does not in any way resolve a problem, it's not a very good answer :) – Oddman May 03 '13 at 03:33

5 Answers5

14

I recommend using git over SVN. Easier branching and merging means that all of these points will go more smoothly for you.

Applying upgrades: Do this in dev. Make a branch (this is where git really shines), apply the patch files or even better, unpack a new Magento version and point it to your old database. No extensions yet. Open the admin in the new Magento installation an hope for the best. Upgrading between minor versions probably won't be a problem. You will probably have to reindex after all the new stuff installs. Do a commit once this is stable, then gradually bring into the branch your extensions and themes, make any code adjustments, then doing a commit after each step proves stable.

Environment-dependent files: .htaccess and app/etc/local.xml. I do a separate version for each: local.dev.xml, htaccess-dev local.staging.xml, htaccess-staging local.production.xml, htaccess-production

...and then make softlinks to them for each environment:

ln -s htaccess-dev .htaccess
cd app/etc/
ln -s local.dev.xml local.xml

and so on.

Restricting access to certain developers: I don't do this. However, you can develop a deploy strategy in git that lets a release manager decide what goes in and what doesn't.

Managing database changes: That's the trickiest part. We just use mysqldump from production, and have some ready-made "env-setup.sql" files for each environment. Something like this (your ids may vary):

UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4);

I usually add some more instructions that will change payment gateways over to test environments, change outgoing emails, etc. Most of these you will find in core_config_data.

Remember that modules will usually make their own changes to the db, so applying a well-made module usually takes care of itself. In any case, never apply untested changes to prod, always do "rehearsals" on local and staging environments.

You can get the CMS (pages and static blocks) data out of the database by dumping and loading just the cms_* tables from whatever environment development was done on.

Good luck!

Greg Robbins
  • 610
  • 5
  • 9
  • Any chance you can post an example of one of your env-setup.sql's? – Joe Fletcher Jan 11 '12 at 06:59
  • 3
    FYI, Magento globs and loads all the `*.xml` files in the `app/etc` directory so it's best to name them something like `local.xml.dev` (or put them in a different directory). That way they won't be loaded in the other environments. – webbiedave Apr 21 '14 at 20:17
9

I use the same best practices as of any web app while developing magento. I also religiously avoid making any changes to the core files (many documents on the magento wiki ask you to modify core files).

Rick J
  • 2,723
  • 2
  • 22
  • 31
7

I use git to manage all of my Magento projects and deployments. It's much easier to merge new versions, especially if you use the Magento mirror I maintain on github. (GitHub Magento Mirror)

As for you specific question about where the base url is stored in the DB, try this:

SELECT * FROM core_config_data WHERE path = "web/secure/base_url" OR path = "web/unsecure/base_url";
  • @JonathanDay there are a few `magento-mirror` repos: https://github.com/search?q=magento-mirror&p=1&ref=searchbar&type=Repositories&l=, though dunno how all these compare/are related to the one mentioned in the answer. – Halil Özgür Nov 30 '12 at 07:51
3

You can avoid the DB-Manipulation (in german): http://blog.tudock.de/startseite/beitrag/2010/09/17/deployment-prozess-eines-magento-shops.html

Felix
  • 1
  • 1
  • So good! There's also an english translation attached. This is awesome! Btw instead of stores you can also do it on website scope basis: ` http://whatever.url/ https://whatever.url/ ` – workflow Oct 01 '14 at 22:29
  • @workflow Can you help wiht the english translation version since you said you found it. Am not able to find it. – Vinu D Jul 24 '15 at 18:46
  • 1
    @VinuD Can't find it either - think it was in a comment and has probably been lost in a move or something. The author is stating that magento usually overrides your local.xml settings with the ones in DB. However, you can use a trick to specify settings in local.xml for deployment: Set values (in db) for your default store (default scope), and leave them blank for all specific websites / stores / store view. You can now use local.xml to override the default values for specific stores or websites, like in the example near the bottom of the blog post. Contact me if you need to know more. – workflow Jul 25 '15 at 23:01
3

After a lot of trial and error, we've come up with a workflow that suits us well:

http://www.dhmedia.com.au/blog/perfect-magento-workflow-using-git

Includes database management, all code under source control (with Git), deployments, staging and development sites, multiple developers, multiple environments, etc...

Hope this helps someone!

jmlnik
  • 2,867
  • 2
  • 17
  • 20