84

Setting up a Magento store is not only a matter of developing self-installable extensions but requires also a lot of "manual entry" operations such as creating end editing attributes, categories, products, price rules CMS pages and so on, not to mention all the changes to the System Configuration.

I'd like your help to outline the best strategy when it comes to deploy a Magento store from development to staging and production environment.

One strategy of mine is that of writing a "deploy module" which programmatically creates the entities mentioned above but it's a very time consuming task and sometimes it seems to me to be a little overkill.

Recently I started using Selenium IDE to reproduce Admin tasks but the time required to set up all the test suites is not far from the one mentioned above.

Maybe an optimal solution could be the usage of a module capable of doing a snapshot of a Magento System letting you choose what to deploy.

So:

  • what is your strategy for deploy?
  • is there a module capable of doing a snapshot of a Magento System letting you choose what to deploy?
  • if such a module doesn't exist and provided such a module is a reasonable solution, is there anyone interested in giving his/her contribute to develop it?

Thank you!

Improve this question
6
  • This might point to the need for another tag or tag category. Are you a one-off shop or are you looking for general suggestions as a service provider? If the latter, any answer would have to be peppered with "depends on how much control the client wants over entity data".
    – benmarks
    Commented Jan 26, 2013 at 22:21
  • My point of view is the one of a developer belonging to a dev team. Suppose I'm developing a section which needs some data to function, say a category structure. I create the structure via Admin, do the code and push my code. I'm wondering whether the best strategy is to also write and push code which creates the needed category structure. What if my category structure or settings conlict with the ones by other developers who pushed their own? How do I handle conflicts? That's my point.
    – Alessandro Ronchi
    Commented Jan 27, 2013 at 8:13
  • @AlessandroRonchi This is a moot point, and a conflict that should never happen. Your category structure is not something that should frivolously change, thus one developer should not be pushing out a major change to your structure, without the other(s) knowing about it. If this does happen, you need to address your inter-dev communication. Generally the category structure for a site needs to be pinned down from day one, and never need to change again, just get added to. If you do need to change it, you did not scope it out correctly the first time.
    – ProxiBlue
    Commented Jan 28, 2013 at 10:04
  • @dedmeet unfortunately, in the world I know and work in, things change every day; customers change their mind, developers change their mind, black swans occur. I have to be prepared to changes; anyway even if category structure doesn't need to be changed from day one it's only a small piece of the whole part and the whole part is a "work in progress" project that is supposed to change in order to get things done.
    – Alessandro Ronchi
    Commented Jan 29, 2013 at 9:03
  • ok, granted, we do work in an ever changing environment, but I still stand that a category structure conflict should not happen. Multiple branches should not exist where each changes the structure, that will just lead to problems, and waste of dev time. Why is dev a spending time making structure changes, whilst dev b is doing the same, to a different structure, and they both push their work? If the structure must change, all devs involved in the project must be involved in the process of scoping out the new structure. Can you provide an example to help me understand when this may happen?
    – ProxiBlue
    Commented Jan 29, 2013 at 13:37

6 Answers 6

Reset to default
41

My opinion is to script it all. I usually have a base config module for anything that is not directly related to a specific modules functionally. ( example creating custom url rewrites for previous site url to new site url) and add anything related to a module to its own install scripts.

The mindset behind this is that if the site needs to be reinstalled, using a fresh db, then everything comes back as you had it. This also helps in the fact that I periodically update the uat site with a copy of the live db. The modules in uat then continue working as they slot in their configs again.

Changes to postage rates, cart rules etc. (basically things clients administer themselves in admin) is considered 'volatile data' and is not scripted. This includes product data. The client has the option, and is encouraged to test new imports on the uat site first.

Clients are told not to create attributes, but rather have them created via a ticket request. This then enables me to also gather information on what the clients intention for the attribute is, and sometimes I have a better suggestion, or can create better code as I have a handle on what attributes exist, plus on selectible attributes, ensure the data is clean.

Yes scripting takes longer, but it will take a lot longer to recreate a whole sites config settings manually later. It can also be embarrassing if you forget something and cause the site to not function properly, or have a new dev work on a local site that is missing some crucial config setup.

Improve this answer
2
  • 1
    I do agree with dedmeet. When you first learn how to script all the updates, it may be more initial work but if you have to apply configuration updates manually for 3-4 developers, staging, uat and live, the coordination and actual work is going to take much longer. Our workflow is pretty similar: if the config is needed for a (reusable) extension, put it there. If the config is client-specific, put it in a project-specific extension. One of the few exceptions are cart rules which aren't fun to update/create at all.
    – Matthias Zeis
    Commented Jan 27, 2013 at 16:39
  • 1
    I just release a module which helps create the required config script, thus eliminating the mundane work of having to manually create the install scripts. The module uses a grid display of the core_config_data table to allow selections of the config values to export. Make my life just a little bit simpler, and I hope it will work for others. proxiblue.com.au/blog/magento-config-data-generator
    – ProxiBlue
    Commented Nov 5, 2013 at 14:15
27

I had been some researchs several months ago. Here is the sites that you can refer.

Magento Base URLs and dev/staging installations
Magento Development and Deployment
Magento Git Guide and Work Flow
Quicker Dumping of a Magento MySQL Database for Branching

Improve this answer
3
  • 1
    Thank you, I will read all of them and come back with some considerations.
    – Alessandro Ronchi
    Commented Jan 27, 2013 at 8:14
  • I've read all give resources; I already knew some of them, others I didn't know are very interesting. None of them, anyway, is the solution to my problem and I've decided to sketch down an extension that will try to fulfill my needs. Thank you to all of you that gave me precious advice. I hope to come back here with some results.
    – Alessandro Ronchi
    Commented Jan 30, 2013 at 11:21
  • Dear Alessandro, I would like to see your way which I am looking more comfortable technique as well!
    – Oğuz Çelikdemir
    Commented Jan 30, 2013 at 12:45
18

I'd like to thank all of you because your considerations have inspired and pushed me to develop an extension, called "Mageploy" with the intent of solving the problem of maintaining different environments in sync.

http://www.mageploy.com

Mageploy still has to be extended, well documented and fully tested even if I'm already using it in a couple of projects having some benefits.

It's open source and any help or suggestion wil be appreciated.

Regards

Improve this answer
7

With regards to install scripts and creating entities, my general feeling is that if it's required or expected by a module, it should be created as part of an install script.

Recently, in terms of dev/stage/production, we use the staging site as the master copy of the database for content as it means that the client can collaborate. In the past, probably the biggest issue we've come across is coordinating the content entry with the client, particularly with regards to product uploading.

How were you thinking the snapshot would work? I think in an ideal world, you would have a tool which showed the diff between two databases on particular types (products, categories, CMS etc) and allow you to merge the changes into one another but I'm not aware of anything available like that.

Improve this answer
2
  • 1
    "With regards to install scripts and creating entities, my general feeling is that if it's required or expected by a module, it should be created as part of an install script." This is the most salient point to consider, and applies to config settings. My quick test: when I need a new dev to clone the repo and install the environment, what needs to exist for the system to function?
    – benmarks
    Commented Jan 26, 2013 at 22:23
  • Sharing a staging site with clients to collaborate on configuration is great in theory. In practice, clients don't tell you everything they changed 99% of the time which makes it easy to screw something up. We may allow clients to work on stuff as cart rules, categories, products or the similar but we don't let them interfere with configuration.
    – Matthias Zeis
    Commented Jan 27, 2013 at 16:44
6

In my opinion creating and editing attributes, categories, products, price rules have nothing to do with a "deployment strategy" All these items are pretty unique to a shop, and in most cases demand a proper bit of analysis and research of the products you are going to sell.

If you are creating "one size fits all" shops with similar configuration of all the elements you mention you could just make a "snapshot" export of your database after you have done all the setup you need for every shop.

Improve this answer
3
  • No, "one size fits all" isn't the point; it's the same situation we, as developers, come into when it's time to merge our source code with the one of another member of the dev team: in that case we have source control systems that do the magic. My question was more related to the opportunity of merging "non dev" things such config settings and typical admin settings and entries.
    – Alessandro Ronchi
    Commented Jan 27, 2013 at 8:04
  • Ah ok, That makes it more clear
    – Rutger
    Commented Jan 28, 2013 at 7:42
  • Let's say we are creating a complete new website, so no issues with old data etc Almost all of the time all our devs use the same database for developing. That solves a lot of problems. For other cases i have no better solution (yet) than to write out all the steps needed in some sort of roadmap/script and re-aply them all after merging. If only one person is responsible for the "magento core" admin settings these should not be to many steps. I once found this, but have never tried it tinybrick.com/magento-modules/admin-tools/…
    – Rutger
    Commented Jan 28, 2013 at 7:52
2

I'd like to add two excellent time-saving tools:

  • For development: PhpStorm IDE with the Magicento plugin
  • For deployment: Magentify, a Capistrano recipe for Magento
Improve this answer
1
  • Thank you for informing us about Magentify, I didn't know it and I'll give it a try. My focus, although, was more on synchronizing different development environment than on deploying in the sense of publishing a code base. Mageploy could be integrated with Magentify but is a different tool, used to automatically keep some portion of database changes aligned regardless of specific IDs which are different between different environment. Sincerely, Alessandro
    – Alessandro Ronchi
    Commented Apr 3, 2013 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.