CMS Environments, Development, and Content Workflow Best Practices

Agility CMS is designed to be flexible, easy-to-use, and empower you to do more, faster!

Agility is a headless CMS, thus your content is decoupled from your presentation layer (i.e. your website). Separating your content from your code allows for greater flexibility of how you use that content, it also allows you to maintain separate workflows for changes to content and code. 

This guide will walk you through how you can design content and code workflows that will make it faster than ever to publish content changes, while also maintaining a high level of quality control over it and the code presenting that content.

Instance Environments

Agility is a multi-tenant CMS, hosted and managed in the cloud, by us. 

Agility's flexible content models and page management means you can use Agility to power one or many different websites or apps. In most cases, you will have a single production Agility CMS instance (environment) and its content will be consumed by a website. 

While the Agility CMS instance and our APIs are managed by Agility, the website(s) are managed by you. 

With your production CMS environment, all content can be previewed prior to publishing. When you Preview your content from the CMS, Agility will open a new tab in your browser and initiate a preview session using your configured preview website.

Additional Instance Environments

Additional instance environments represent replicas of your production instance, designed for developers to test changes to their content architecture before implementing a change in your production instance environment. This re-enforces the separation of concerns between code and content by allowing developers to validate and test their code with a variety of test content separate from the production content.

Developers should have access to additional instance environments to test changes, while editors who need to manage content should only have access to the production instance environment.

Whether you need additional instance environments or not will depend on how large your team is and what level of risk you are comfortable with.

It's important to note that additional instance environments are not designed to be used by editors or as part of a typical content workflow. We recommend keeping all content workflow within your production instance, utilizing the built-in workflows for content.

Website Deployments

It is important to note the decoupled nature of the CMS and your website.

You can have as many different website deployments as you'd like (per instance) and you can register them in Agility CMS so that content editors can view how their content looks in different website environments.

For example, a typical setup will involve having a local development website deployment, a uat/staging website deployment as well as a production website deployment. This allows you to develop locally, and test and review code updates in uat/staging prior to deploying your code to production.

While you can have multiple website deployments, there is only one Agility CMS instance that houses your configuration settings and content. This makes it easy to access the same content across multiple website environments.

When connecting your website to Agility CMS, you need to determine if you will pull the latest content (preview) or published content only (live).

Your production site should ONLY show published content, while your UAT site should allow editors to preview their changes before publishing them.

  • Production Website Deployment = Published content only (live)
  • UAT Website Deployment = Latest content (preview)
  • Dev Website Deployment = Latest content - if you are using a Sandbox CMS environment, then the dev website can point to that instance directly to pull developer-created test content

Deployment Workflow

When building solutions that use Agility CMS (i.e. a website), the general approach for a developer is:

  1. Model your content in the CMS - beware of introducing breaking changes to your content architecture
  2. Initialize some content (in Staging, do not Publish yet) to test retrieving data
  3. Code how the content will be displayed in your local website development deployment
  4. Test your code/output
  5. Deploy your code to a hosted website that editors can use to preview content using your new code - this website should be configured to show the latest content, not published content only

Development Workflow with a Sandbox

If you have a development sandbox CMS environment, then your developer workflow will be a little bit different:

  1. Model your content in the sandbox CMS instance
  2. Initialize some test content in your sandbox to test retrieving data
  3. Code how the content will be displayed in your local website deployment, this must be connected to pull content from your sandbox
  4. Test your code/output
  5. Review changes on a dedicated dev website deployment (a deployed version of your local codebase)
  6. Synchronize (manually) any changes you have made to your content models from your sandbox to your production CMS instance
  7. Deploy your code to a hosted website that editors can use to preview content using your new code, connected to your production CMS instance - this website should be configured to show the latest content, not published content only

Content Workflow

New code or changes to content definitions are typically handled by developers and they will either do this in a Sandbox CMS instance first or directly in the production CMS instance. Editors should only have to focus on one thing, content!

A typical editor workflow looks like this:

  1. The editor creates a new piece of content and it is placed in Staging mode - this means it can be previewed for accuracy on the UAT (preview) website but is not yet available to the production website
  2. When ready, the editor Requests Approval to publish the content
  3. The designated approver previews the content on the website and determines whether changes are required or it can be approved
  4. Once Approved, the content can be Published
  5. Published content is now shown on the production website
Content workflow diagram with Agility CMS

Implementing a content workflow such as above allows editors to focus on writing good content while designating an approver to manage if and when content should be published and made available for production. Keep your editors productive, while maintaining a high level of quality control.