publishing workflow / best practices
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: publishing workflow / best practices
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: publishing workflow / best practices
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
Yes, please!! This is what I had in mind for a longer time, but never managed to start working on it: A WebDAV-client-tool that determines the server capabilities by doing some OPTIONS request and retrieves the content by doing the appropriate WebDAV-requests afterwards. This would have the big advantage that it works with different WebDAV-based repositories and works if different Slide instances use different storage configurations. It might be a bit tricky to retrieve not only the content but also properties, locks, acl and versioning information, but it finally would be the most elegant solution. If we find a good XML representation for content/properties etc. we could use this for data import as well. The xml-format could consist of nested elements representing each resource. This would enable to "dump" the repository located under a given path and import it to a different location. Optional flags could be used to ignore locks/acl/versioning information. Just a dream... or is someone interested in implementing this? As stated before I had this on my personal roadmap for a while but am very busy at the moment and can hardly find the time to do it. Cheers, Daniel "Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am 24.11.04 23:04:34: > > 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
Re: publishing workflow / best practices
Maybe we could use the dump format used by subversion. I don't know anything about it other than subversion uses for dump/restore and that importing data from CVS is done by first converting the CVS repository to this format and then using the regular restore tool. It handles properties and revisions but I don't think it handles ACLs or locks but it could probably be extended if there's need. I'm suggesting this because if starting from scratch, anyway work has to be done on the dump format and it would add interoperability with CVS and subversion right away without additional work. Daniel Florey wrote: Yes, please!! This is what I had in mind for a longer time, but never managed to start working on it: A WebDAV-client-tool that determines the server capabilities by doing some OPTIONS request and retrieves the content by doing the appropriate WebDAV-requests afterwards. This would have the big advantage that it works with different WebDAV-based repositories and works if different Slide instances use different storage configurations. It might be a bit tricky to retrieve not only the content but also properties, locks, acl and versioning information, but it finally would be the most elegant solution. If we find a good XML representation for content/properties etc. we could use this for data import as well. The xml-format could consist of nested elements representing each resource. This would enable to "dump" the repository located under a given path and import it to a different location. Optional flags could be used to ignore locks/acl/versioning information. Just a dream... or is someone interested in implementing this? As stated before I had this on my personal roadmap for a while but am very busy at the moment and can hardly find the time to do it. Cheers, Daniel "Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am 24.11.04 23:04:34: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: publishing workflow / best practices
I'm not sure, but I think these two ideas might be of slightly different magnitudes. I think the original request was how to migrate the minimal amount of information from a dev/staging instance to the live instance. Therefore one would not need/want to take all version/meta information across. It would be a simple "copy from stage to live" sort of function. I have been thinking about how to implement such a solution as well, but my solution was not going to store the "live" data in a webdav repository, just on a filesystem. (I'm not a fan of storing files in a database, so I use the filesystem store anyway) I think Daniel's idea was much broader about a full mirror/migration for ALL Webdav content and information. I definately agree that would be a great tool, but I think it might be overkill for the "stage to live" workflow. I guess that is assuming you are moving items piece by piece as they are approved. Tim Daniel Florey wrote on 25/11/04 03:03 AM: Yes, please!! This is what I had in mind for a longer time, but never managed to start working on it: A WebDAV-client-tool that determines the server capabilities by doing some OPTIONS request and retrieves the content by doing the appropriate WebDAV-requests afterwards. This would have the big advantage that it works with different WebDAV-based repositories and works if different Slide instances use different storage configurations. It might be a bit tricky to retrieve not only the content but also properties, locks, acl and versioning information, but it finally would be the most elegant solution. If we find a good XML representation for content/properties etc. we could use this for data import as well. The xml-format could consist of nested elements representing each resource. This would enable to "dump" the repository located under a given path and import it to a different location. Optional flags could be used to ignore locks/acl/versioning information. Just a dream... or is someone interested in implementing this? As stated before I had this on my personal roadmap for a while but am very busy at the moment and can hardly find the time to do it. Cheers, Daniel "Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am 24.11.04 23:04:34: 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
Re: publishing workflow / best practices
I was thinking of a tool that could be used for different purposes. So if you want to use it as a staging tool, you could call it with some options so that only content/properties are dumped into a single xml file. Versions/Locks could be ignored in this case. This single XML-file could be imported on the live machine in a single transaction. The big advantage is that you are independant of the underlying store. Cheers, Daniel "Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am 25.11.04 15:41:15: > > I'm not sure, but I think these two ideas might be of slightly different > magnitudes. I think the original request was how to migrate the minimal > amount of information from a dev/staging instance to the live instance. > Therefore one would not need/want to take all version/meta information > across. It would be a simple "copy from stage to live" sort of function. > I have been thinking about how to implement such a solution as well, but > my solution was not going to store the "live" data in a webdav > repository, just on a filesystem. (I'm not a fan of storing files in a > database, so I use the filesystem store anyway) > > I think Daniel's idea was much broader about a full mirror/migration for > ALL Webdav content and information. I definately agree that would be a > great tool, but I think it might be overkill for the "stage to live" > workflow. I guess that is assuming you are moving items piece by piece > as they are approved. > > Tim > > Daniel Florey wrote on 25/11/04 03:03 AM: > > Yes, please!! This is what I had in mind for a longer time, but never > > managed to start working on it: > > A WebDAV-client-tool that determines the server capabilities by doing some > > OPTIONS request and retrieves the content by doing the appropriate > > WebDAV-requests afterwards. > > This would have the big advantage that it works with different WebDAV-based > > repositories and works if different Slide instances use different storage > > configurations. > > It might be a bit tricky to retrieve not only the content but also > > properties, locks, acl and versioning information, but it finally would be > > the most elegant solution. If we find a good XML representation for > > content/properties etc. we could use this for data import as well. > > The xml-format could consist of nested elements representing each resource. > > This would enable to "dump" the repository located under a given path and > > import it to a different location. Optional flags could be used to ignore > > locks/acl/versioning information. > > Just a dream... or is someone interested in implementing this? As stated > > before I had this on my personal roadmap for a while but am very busy at > > the moment and can hardly find the time to do it. > > > > Cheers, > > Daniel > > > > > > > > > > "Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am > > 24.11.04 23:04:34: > > > >>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 ou
