Sync Content Only to Specific Web Server(s)

Pinned Featured

Comments

6 comments

  • Aleksandar Shumanov

    1. Yes

    2. Of Course

    3. Nope

    4. We were waiting for this for such a long time. Of course we will use it.

  • James Vidler

    Thanks for the feedback Aleksandar! 

  • Giovanni Mattucci

    This feature would be very welcome, and would make changing existing content definitions much less of a "walking on eggshells" kind of operation.

    If this feature was only applied to Modules and Content Definitions it would be of great benefit.

  • James Vidler

    @Giovanni - great point about the Module/Content definitions, we'll have to consider that too. 

    Specifically how to handle this case:

    1. You have a module definition with a field called "Field A".

    2. You add a new field to the module definition called "Field B".

    3. You publish that module definition and only sync that to your stage environment

    4. An editor opens up an instance of that module on a page - it shows "Field B"

    5. Editor enters a value for "Field B" and publishes and sync the update to stage environment AND production environment

    6. User is presented with an error message saying cannot publish module to production environment, because the definition is not published in production. The module is published on the stage environment.

    @Giovanni - What do you think of this way to handle it? It is sort of an extension of the way we handle unpublished module defs right now.

  • Russ Huntington

    I think this is a great idea.

    In a previous job role (many years ago), we had a deployment process that involved a pre-production environment, which was essentially a copy of production for the purpose of testing the migration before committing to actual production. This was very time consuming - so utilizing the cloud set up of nominating one instance as a temporary pre-production environment seems like an ideal solution.

    I don't think that this would be a good facility for editors however, as it would seem overly complicated. Editors should be able to reliably send content into production at all times, and anything that prevents that from happening needs looking at. Changes to module and content def structures would be the best candidates for this process, obviously.

    I assume then if a pre-production deployment doesn't go well, then that pre-production environment can just be rolled back somehow?

  • James Vidler

     @Russ - thanks for the input! You bring up a great point about being able to "rollback" a synced change. While you could do this manually, it can be a pain, especially if your change included lots of different pages, and content/module definitions and or any website configuration changes.

    I'm going to share this with the product team and see what we can come up with.

Please sign in to leave a comment.