Paul Gutekunst wrote:
> I am looking for some advice on managing multiple development instances using
> the Magnolia Community Edition. Ideally I would like to be able to work on
> multiple features at the same time that are (somewhat) independent from each
> other. Our setup is as follows:
>
> - Instance of Tomcat with author/ROOT.
> - We have docroot/templates managed under version control.
> - We have our own module in WEB-INF/lib managed under version control.
> - Anything magnolia related (templates, dialogs, paragraphs, config) is
> managed by hand and move from one instance to another using magnolia
> export/import.
> - From time to time we copy production and put it on our development
> instances to keep things up-to-date.
> - All development instances sit on a server on our network accessible to
> developers.
>
> Right now we have two development instances that are completely independent
> from each other i.e their own tomcat, docroot/templates/module, and magnolia
> repo. This turns into a hassle because more often than not one instance gets
> way out of date from the other, making the older instance useless until
> someone (me) synchronizes it. I can see firing up a third maybe a fourth
> instance in the future as we work on new things or have R&D todo. I'm
> starting to think that maybe all these instances should share the same
> persistence manager. Should I move the repository to a common place? Should I
> move to PostgresSQL? If you recommend I do something like that, what things
> will I need to change to make this work? Is there any other advice someone
> can provide that will help? It would be greatly appreciated!
What is in your own module if 'Magnolia related things' are managed manually?
We use a central repository for developers to do their configuration changes.
This way everyone doing development connected to this database sees the changes
immediately. Of course these changes still need to be exported to XML for
bootstrapping.
But you can also run Magnolia using a local repository if whatever you're
working on works better that way. We use sample sites for local development.
Dumps from production are pushed to staging and testing from time to time.
I would recommend reading this three part series on Magnolia CMS written by
Grégory from Magnolia and moving away from managing anything manually:
* Don't build Magnolia: build your projects.
http://dev.magnolia-cms.com/~gjoseph/dont-build-magnolia-build-your-projects
* Don't configure Magnolia: let your projects configure it.
http://dev.magnolia-cms.com/~gjoseph/dont-configure-magnolia-let-your-projects-configure-it
* Don't deploy Magnolia: deploy your project.
http://dev.magnolia-cms.com/~gjoseph/dont-deploy-magnolia-deploy-your-project
Nils.
----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
