publishing workflow / best practices

[Mirko Froehlich <mf...@digitalchocolate.com>]

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

Webdav copy across Slide namespaces

[Richard Emberson <re...@edgedynamics.com>]

Does Slides implementation of the webdav COPY method allow one
to copy a resource or collection across Slide namespaces?

Richard

-- 
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: publishing workflow / best practices

[Mirko Froehlich <mf...@digitalchocolate.com>]

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
> >>>
> >>>
> >>
> > 
> 

Re: publishing workflow / best practices

[Richard Emberson <re...@edgedynamics.com>]

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
>>>
>>>
>>
> 


-- 
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: publishing workflow / best practices

[Mirko Froehlich <mf...@digitalchocolate.com>]

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
> > 
> > 
> 

Re: publishing workflow / best practices

[Richard Emberson <re...@edgedynamics.com>]

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
> 
> 


-- 
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org