It sounds like writing a client tool to migrate content from one Slide server to another one might be a good option. This should be fairly simple to write using the Webdav client library. Another option that I originally had in mind is to simply perform a database dump on the staging server and upload this to production. Of course, this would preserve the entire version history, which we most likely won't care about on our production server, so a separate tool might be more appropriate.
-Mirko On Wed, 2004-11-24 at 13:58, Richard Emberson wrote: > I must preface my remarks by stating that our Slide deployment will use > a database for storage. > > Consider Slide namespaces. From what I've heard and based upon the > mailing list traffic, multi Slide namespace installations do not > occur very often. Lets say that such installations work just fine, > - each namespace could use a different database - > one would need some external Slide/webdav tool/script to promote > (copy) directories from dev namespace to test namespace to production > namespace. > Since one has to create and use such a promotion tool, its not clear > that having a single Slide with three namespaces buys one anything > over having three distinct Slides each with their own DB. > I am assuming that to promote a directory involves getting it (the > whole directory hierarchy) into the (client) tool from one Slide > server and then putting into a second Slide server. > This is true even if one has the three Slide databases on the same > database server; one must extract the directory from one db and > insert it into another. > > Our dev Slide server will be version controlled while the test and > production need only have non-versionable copies. > > > Mirko Froehlich wrote: > > Our current staging environment really serves a different purpose. Our > > test, staging, and production servers correspond to phases in our > > software development cycle and are strictly separated. We definitely > > wouldn't want to use the production Slide server for development or test > > purposes, so those at the minimum would need to be separate servers. > > However, my example of publishing web content from staging to production > > uses a different concept of staging than we currently have, so it may > > not be an ideal example. I suppose for this scenario the content could > > very well live in two different folders on the production Slide server, > > with a simple publishing process that copies or moves content from the > > staging to the production server. I guess in the end this really depends > > on the workflows we need. For example, for content updates on the live > > site this approach would probably work well. But lets say we develop a > > new major version of the application with significant changes to our web > > content management framework and corresponding new content in the > > repository. When this goes live, we would need to publish the content > > from the staging Slide server to the production server. > > > > I know this is somewhat hypothetical at this point. I'm just trying to > > get a feel for how people use Slide. Yours is definitely a viable > > option. > > > > -Mirko > > > > > > On Wed, 2004-11-24 at 12:58, Richard Emberson wrote: > > > > > >>For my information, why would you not have top-level directories: > >>dev, staging, and production; all within the same Slide server? > >> > >>Richard > >> > >> > >> > >>Mirko Froehlich wrote: > >> > >>>Those of you who are using Slide in a production environment, what kind > >>>of publishing workflow have you put in place? > >>> > >>>We will likely end up using Slide for various aspects of our > >>>application. Initially, it will mostly serve as a repository for > >>>user-specific application data. In this scenario, the user data would > >>>only live on the production server and there would not have to be a > >>>publishing process that moves data from staging to production. However, > >>>there's a good chance that we may end up using Slide for web publishing > >>>as well, in which case we would probably want to be able to manage > >>>content on the staging server and push it to production as part of a > >>>publishing workflow. > >>> > >>>I suppose this could be as simple as performing a database dump on > >>>staging and loading it on production. We would probably set up multiple > >>>db stores, which would allow us to publish the part of the repository > >>>that is used for web publishing, but not the part of the repository that > >>>contains the users' application data. > >>> > >>>Anyway, I would be interested in hearing about your experiences and best > >>>practices that you have determined for these kinds of scenarios. > >>> > >>>-Mirko > >>> > >>> > >> > > >
