Sync Content Only to Specific Web Server(s)

The Problem we are Trying to Solve

How can you be sure that the content/definition you want to publish will not cause any issues in the production environment prior to synchronizing the change?

When you publish content in Agility, it will attempt to synchronize that content with all active/maintenance mode web syncing web servers. This usually means your production website and your staging website.

The problem this presents is that there's no reliable way of testing your published content before it is synced to your production website. Ideally, it would be beneficial to test these published content changes on your staging website first in Live Mode and with caching. That way you have a test environment near identical to your production environment.

With Preview Mode, you can test the latest content on stage/production before you publish, however previewing can be slow and you still might forget to publish specific content which can cause a bug on rendering content on the website.

Workaround

A workaround for this solution for this right now is to Deactivate the production syncing web server temporarily while you publish your content and sync it to your stage website. This isn't a great solution though, this means that while your production syncing is deactivated, you cannot sync ANY content to the web server. If you identify an issue that needs to be resolved, you need to resolve it prior to activating your production syncing web server.

More info:

Testing CMS Changes Prior to Synchronizing to Production

Potential Solution

Internally, we are discussing the possibility of allowing you to manage which syncing web server you want to Sync content to. Rather than syncing across all web servers, if you had more control over which environment and when, this can allow you to do full live testing in environments that replicate your production website prior to synchronizing your content to production. You would also be able to continue to sync other types of content to production, while choosing NOT to sync others.

Benefits:

  • Speed up UAT review: No need to preview content, since it would be synced to the environment
  • Less bugs in production: Allow testing published content in a pre-production environment before you publish to it
  • Parallel workflows: you can test pre-production content but also still publish other content to production 
  • Reduced risk in deployments

Challenges:

  • How to show in the CMS that some content is published/unpublished, synced to some environment(s) but NOT synced to others?
  • How to handle syncing of content and module def changes
  • How to handle syncing of configuration changes in Settings?
  • How to handle 'rollbacks' if a content/def/config change sync breaks pre-production
  • Should batches play a part in this?
  • How should this work with the REST API or Server API - there is no concept of 'synced' content for those

We want YOUR Feedback!

Please share your feedback in the comments below this post.

  1. Do you think this is a feature that would help editors review content in a quicker and more reliable manner?
  2. Do you think this should result in less bugs in production?
  3. Do you think this additional layer adds too much complexity?
  4. Would you use this?

If you have any additional comments or feedback please let us know in the comments. Like/Dislike the idea? Up/Down-vote it by clicking the voting buttons in the top-right of this page.



2

Comments

6 comments
  • 1. Yes

    2. Of Course

    3. Nope

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

    1
    Comment actions Permalink
  • Thanks for the feedback Aleksandar! 

    0
    Comment actions Permalink
  • 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.

    0
    Comment actions Permalink
  • @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.

    0
    Comment actions Permalink
  • 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?

    0
    Comment actions Permalink
  •  @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.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post