Hi BigLee! I find your question very interesting, we are facing a very similar situation. We are still working on finding the best ways to accomplish the migrations.
Here is a summary of our experiences so far: As Jan describes, the module mechanism in Magnolia is excellent! Modules can be used to easily "move" functionality between instances. The install-procedure for the modules is very "intelligent" - you can code ModuleVersionHandlers and DeltaVersionHandlers which will intelligently install your module, and can check the state of the repository to perform different install-tasks depending on this state (for example, the module can install differently depending on whether it is already installed before, or depending on whether it is an author or public instance that is being installed). I find the modules very useful to move functionality (Java-Code like Template and Paragraph Model-Classes) and configuration (your module's config, or changes to the magnolia config) around between instances. However, I do not find that the modules are a good way to move content around. Content is usually created by someone else, while the modules are created by a Java-Programmer. To incorporate content into the modules requires a lot of communication between these people. Also, there is no "easy" way to move content from the repository into your Java Project - each time the content changes you would have to do something like a new XML-Export, update your module version number, change your DeltaVersionHandler, etc... That's really a lot of work, esp. when moving from development to test and back. For moving the content around, we are currently using magnolia's "packager" module. The packager is a nice tool that allows you to define a "bundle" of content (also from multiple workspaces), and export it in a ZIP file. That ZIP file can be uploaded and installed in another magnolia instance. This method works ok, but once you have several sites, and especially if the content is changing a lot (as is normal during development), this method also becomes quite a lot of work. So we are currently investigating better methods of handling content-migrations, and currently have the following ideas: 1. By changing the JackRabbit configuration it is possible to store the entire repository (except the SearchIndex) in a Database (use DbFileSystem, DbDataStore and DbPersistenceManager for all FileSystems, DataStores and PersistenceManagers, see JackRabbit documentation). Combined with configuration where connections are obtained from JNDI, this yields a setup where: - All Content is stored in the Database - The DB-Connection is configured in Tomcat (GlobalResources or Context Resources), meaning the Repo Configuration File is *exactly* the same on the different instances - This means that by shutting down magnolia, dropping the databases, and importing the database-dumps from another instance, you should be able to transfer the entire repository in one swoop 2. By activating the RMI-Access in JackRabbit, it should be possible to access the repository from outside magnolia. - This would allow us to write an external "sync-tool", which transfers content between 2 magnolia repositories 3. Use Virtual-Machine-Snapshots - By running magnolia in a VM, including any required Database, we should be able to take a snapshot of the VM, and transfer this to another computer to create another magnolia instance with exactly the same content and setup. I would be happy to share experiences with you on this subject, if you are interested. Regards from Vienna, Richard -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von BigLeeH Gesendet: Donnerstag, 20. Jänner 2011 19:10 An: [email protected] Betreff: [magnolia-user] Develop, Test, Production Instances I am new to Magnolia so kindly forgive me if this is a well-explored topic but I am having trouble finding where it has been documented or discussed. I work for a development company that is producing a new website to be managed using Magnolia. The intention is to have three instances of the site -- development, testing and production -- where the development and production instances will be used to create and test new templates and custom workflows and the production version will be used by the end user to manage their content. Each of the three instances of Magnolia will include both an authoring and a 'public' side although the 'public' side of the dev and test instances will still be inside the firewall of the development organization. Work in the development instance will mostly concern itself with new templates and workflows, and the content will mostly be selected to facilitate testing of those new templates and workflows. The test instance will use the new templates and workflow and will be populated with actual content that parallels the production content (with adjustments to accommodate any template changes) so that at the time a new version (of the templates and workflow) is released into production the content differs from the production content only in those areas impacted by template changes. I have been tasked with designing and documenting the migration procedures for moving information between these instances. I've done a bit of searching in the documentation, mailing lists and various online discussions and I haven't turned up much on best practices in such an environment. It's a bit hard to tease out dev/test/prod migration of templates and workflow as a topic from the authoring/publishing discussions. Can anyone point me at information that might help me? Thanks -- View this message in context: http://old.nabble.com/Develop%2C-Test%2C-Production-Instances-tp30721828p30721828.html Sent from the Magnolia - User mailing list archive at Nabble.com. ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
