Staging Area for Cascade -- Is it necessary?
Hello,
We are planning to do some restructuring of our web development servers, and in the process we're trying to simplify our network topography.
Currently, we have a dedicated machine for Cascade that pushes files to a temporary"staging" area on a different server. It then synchronizes with two separate servers (our web farm) via cronjob every 5 minutes.
We're trying to decide if we need to have this temporary staging area, or if we can publish directly to one live server (our local web farm will be moving to a virtual/cloud hosting environment). It seems like it would be nice to eliminate the delay. Our only concern is when we run "Publish All Sites", we don't want it to eat all the resources of our production server. But maybe that fear is unfounded.
In any case, can you shed some light on best practices for setting up Cascade Server? Have people used it successfully without a temporary staging server?
I hope this question makes sense. Thank you for your time!
Discussions are closed to public comments.
If you need help with Cascade CMS please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Joel on 09 Jan, 2012 02:56 PM
Hi,
I don't believe the staging server is needed here. If you should run into resource problems when publishing across all sites, then you could always fine tune the resources allocated to Cascade Server, as well as which destinations are publishing out (i.e. some Destinations may not need to be published out every time).
As for best practices in setting Cascade Server up, typically clients have two instances of Cascade Server: A test instant and a production instance. The test instance from what I've seen is primarily for testing new versions of Cascade Server against your database and integration, to see if any updated do not coincide with it. The production instance is obviously the main instance where development work is performed in, etc. I have also seen a third instance for solely development purposes, but this requires your users to manually copy over the integration performed in the development instance to production when the development has been completed.
As for a staging server, I have not seen a scenario set up in this way, as most staging servers are related to the development instance I touched on above, publishing out from the development instance to the staging server to simply test integration before going live.
Thanks!
2 Posted by mstevens on 09 Jan, 2012 03:29 PM
Thanks Joel, this is helpful. We're looking forward to moving from 10 servers to 3, and I think our users will be receptive to a more responsive publishing workflow.
3 Posted by Joel on 09 Jan, 2012 04:10 PM
Good deal, glad we could help!
Joel closed this discussion on 09 Jan, 2012 04:10 PM.