> Once you want to start testing in different environment, you just take that 
> webapp and deploy. Magnolia supports multiple instance configuration 
> mechanism that allows you to deploy one war in different servers (or under 
> different context) with different configurations w/o need to rebuild the war.


Documentation about this feature:
http://documentation.magnolia-cms.com/cookbook/using-a-single-war-file-with-multiple-configurations.html

--Antti

On Jan 21, 2011, at 8:49 AM, Jan Haderka wrote:

> 
>> 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.
> 
> AFAIK this is quite common setup for middle to big installations of Magnolia.
> 
>> 
>> 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.
> 
> The way Magnolia aids you during the process of development and deployment in 
> different environments is via modules.
> 
> The common workflow here is to create 1..n Magnolia modules that your 
> developers then work with.
> Decision whether you need one or more modules is completely arbitrary to 
> allow you reuse the functionality or just simply categorize and split up all 
> the work in logical blocks.
> On top of that I would suggest you use maven to create final webapp by 
> overlaying CE or EE webapp with addition of your own modules.
> 
> Each Magnolia module can contain java code, bootstrap files for the 
> configuration and content and of course the templates (be it jsp or 
> freemarker).
> On top of that, each module can have so called VersionHandler class that can 
> programmatically change configuration of other modules as necessary for your 
> deployment.
> 
> So devs export all the config changes in form of the bootstrap files or tasks 
> in Version Handler, put it together with the templates (and possibly some 
> initial content) in the module(s) which are then packed in the webapp.
> 
> Once you want to start testing in different environment, you just take that 
> webapp and deploy. Magnolia supports multiple instance configuration 
> mechanism that allows you to deploy one war in different servers (or under 
> different context) with different configurations w/o need to rebuild the war.
> 
> If there are changes, devs make them, bundle the war file again and QA 
> deploys that in test env again ... and so on. And of course you use the same 
> war then to deploy in production environment.
> 
> Don't have the links on me, but various parts of the above are described all 
> at http://documentation.magnolia-cms.com
> 
> HTH,
> Jan
> 
> 
> 
> ----------------------------------------------------------------
> 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]>
----------------------------------------------------------------

Reply via email to