Overview

Releases allow you to set up collaborative workspaces where future sets of content can be worked on in real-time. Content can be created, edited and deleted in the workspace and then scheduled for publishing at a future date. Scheduled publishing allows your content to "go live" automatically - merging your content changes back into the mainline while triggering release actions for things like:

  • Email Notifications
  • CDN Synchronization
  • Web Hook Calls

Releases give your content team the ability to use Scheduled Publishing. Releases build on top of the underlying Branching capabilities of Cloud CMS. They utilize branches under the hood while providing easy-to-navigate workspaces, activity tracking and scheduled publishing. Releases are often used to produce a final content production for release at a future date, often to a web site, mobile applications, catalog or external data store.

How Releases Work - An Example

Let's imagine that you're using Cloud CMS to publish content for a digital online magazine. The magazine is delivered via a front-end web site. Our goal is to create some new content, push it live and then inform the web site when the new content is available.

You'd start by creating a Friday release. Once it is created, your team can switch to the Friday release within the user interface and create content just like they always do. They use forms, they use workflow, they build new and interesting stuff.

When they're happy with their changes, they "finalize" the release. Finalizing the release tells Cloud CMS to look at any other releases that are already finalized and scheduled and which may conflict with your release. If conflicts are discovered, they are recorded and your team will be given that task of resolving those conflicts.

For example, suppose that while you were busy working away on the Friday release, a separate decision was made to release a "quick fix" update for Wednesday. Perhaps some new content was added to the Wednesday release that your Friday release would not have. If the Wednesday release were already Finalized and locked in, then when you try to Finalize the Friday release, Cloud CMS will discover this discrepancy. In this case, it will automatically solve this for you and pull the Wednesday content into your Friday branch for you.

However, what if the Wednesday branch did something like delete a piece of content that you updated in your Friday branch. In this case, pulling the Wednesday deletion ahead into Friday would delete your changes. Obviously, this isn't what you intended and so this is recorded as a "merge conflict". A merge conflict is basically an excuse to grab a cup of coffee and walk over to your coworker's office to have a chat. You will need to figure out between the two the right course of action for Friday - either keep your changes or delete or something else.

Most of the time, you won't have to deal with conflicts. You're naturally work stuff out ahead of time through conversation so you won't step on each others toes. But if you do, then Cloud CMS provides a few really good options for manual conflict resolution including:

  • side-by-side content forms
  • visual comparison
  • JSON differencing
  • inline editing (A vs B)

Once all the conflicts are resolved (or if you didn't have any), your Release will be finalized. This means that it can be successfully merged with the master branch because all of the potential issues were ironed out ahead of time.

You can now Schedule the release. Scheduling the release adds it to the Cloud CMS scheduler so that a background process will kick off on the release date. The release date is a specific date and time when the release is intended to go live. When that moment arrives, the Cloud CMS scheduler will start the release process for your release.

The release process involves:

  1. Merging your release branch content back into master
  2. Taking a snapshot of the master branch
  3. Some book keeping to mark the release as "released"
  4. Sending any notifications via SNS to load message queues with release availability information
  5. Firing any release actions

Once the release process completes, all of the content from your Release branch will be available on the master branch. In addition, a snapshot is taken. A snapshot is a special kind of branch that is used to capture a frozen-in-time moment of your repository. Snapshots are just like regular branches except that they're read-only.

At this point, you usually want to inform your front-end web site that new content is available. This is typically done by listening for SNS notifications (which are delivered via SQS queued messages to your application server) or by registering a custom HTTP endpoint and receiving an HTTP call to notify that the release went live.

If your web site is making dynamic calls to Cloud CMS, you can have it switch branches to the new snapshot branch that was produced as part of the release process. This snapshot effectively captures that moment in time when the release went live and contains the merged content.

Enabling Releases

To enable releases, you must be a Project Manager. You can then go to the Project Settings page and select the Releases page from the left-hand menu.

Enable the checkbox for "Enable Releases for this Project" and click Save.

Customize your Release

Once Releases are enabled, you can further customize them to do your bidding.

The following options are available:

  • Master Branch can ONLY be updated via Releases

When this option is enabled, the only way to make updates to the master branch will be via Releases. A Release will need to be created, scheduled and then released in order for the master branch to receive new content. Upon release, content from the Release branch is merged into master.

If users try to save content against the master branch directly, an error modal popup will appear informing them that the master branch can only be updated via releases.

  • Maximum Number of Active Releases

In some cases, you may want to limit the number of concurrent releases that are being worked on. This caps the number of concurrent active releases that are in flight. You might use this to inspire your content team to make decisions about old releases that were created but not completed. Or you may inspire the team to work more closely together on activities that are correlated. Either way, capping things can have some positive impact since it drives people to collaborate more closely.

  • Release Actions

When a scheduled release goes live, it does a number of things. For example, it merges to the master branch and also creates a snapshot of your repository at that moment in time. You may want to have some custom stuff happen at this point such as firing off an HTTP call to a custom web hook or sending an email.

See the section below for more detailed documentation about the kinds of release actions you can set up.

The User Interface

When Releases are enabled, they are available on the left-hand side under the "Releases" menu.

The user interface provides three ways to view your releases, both past and future.

  • Calendar
  • List
  • Network

The Calendar view provides a day-to-day view of the scheduled releases so that you can see visually what is coming up and where sources of conflicting or mergeable content may reside. You can, in effect, see what other folks are working on.

The List view provides a list of your releases and allows you to see things like the intended release dates, scheduling activities and more. It also allows you to sort releases by interesting fields so that you can more easily find things.

The Network view provides a subway-map of your releases and reveals how they're all connected together. This is useful for complex release hierarchies as it reveals where in the topography a release was branched and where it was merged back into the main line.