Staging and Production Environments
Permalink
In our agency, we don't make any updates to a live production environment...
Does anyone have any experience in having a staging server setup that pushes or syncs to the production server (in a Concrete5 environment)?
Maybe this is an add-on that could be created? Something that would sync the filesystem, pages etc... but not overwrite comments etc. that are existing on the production site?
Any thoughts would be greatly appreciated.
Phil
Does anyone have any experience in having a staging server setup that pushes or syncs to the production server (in a Concrete5 environment)?
Maybe this is an add-on that could be created? Something that would sync the filesystem, pages etc... but not overwrite comments etc. that are existing on the production site?
Any thoughts would be greatly appreciated.
Phil
The way we do it, it to accept that the live content is not necessary in development and that any updates to content can only happen on live. The basic workflow and versioning that currently exists in C5 is enough to look after the live content and when we need to work on a copy of live, we copy the whole live db and files folder down to dev. The ONLY thing that ever goes from dev to live is code. Never content. Tools like PHPUnit & phing and also hooks in SVN can help to move your codebase around in an automated way and check it for errors.
It's a big deal to get your head around, but once you've got the process nailed, it's pretty slick.
Jon
It's a big deal to get your head around, but once you've got the process nailed, it's pretty slick.
Jon
We have experience doing DTAP development and moving content and functionality around independent of one another, but it's always a painful process that involves someone who knows what they're doing to make sure all is kosher.
We've discussed making a automated solution for this, but it certainly wouldnt be a simple add-on. There's a fair amount of stuff that can change on a live site, just start to wander the add-ons in the marketplace: forums, reviews, etc..
The only way we can wrap our heads around this is to create a standard XML spec that defines EVERYTHING in a concrete5 site and then a queue engine to import/export that data. To be effective the engine would have to handle huge amounts of data while failing in a graceful way (when you're talking hundreds of thousands of nodes in an xml file, it /will/ fail.) The system would also have to import an entire site (replace) or import just part of a site (node, down). It would also have a command line mode, and of course all the blocks would have to be able to share their data via XML through it.
You'd need that to even effectively start doing what you're talking about (move parts of content without others, update functionality without replacing content, etc) and even then I think problems would arise.
Moveover it's going to cost well over 100k to build what we're talking about above.
So the short answer is no. In-context editing is at odds with that level of workflow control and you're not going to see an good solution for that in concrete5 any time soon.
You WILL see a more powerful level of workflow control for concrete5 coming out of us at some point soon tho. Instead of the simple "preview/publish" the ability to create a multi-step process with events and denial paths.. etc.