Publishing Workflows for Connect
Using the publishing methods outlined in this article, organizations can implement a variety of publishing workflows or strategies. This article does not provide a comprehensive overview, but attempts to map common patterns to features available within Connect. These publishing workflows can incorporate best practices like Dev/Test/Prod progressions, peer review, or CI/CD.
Managing Access Controls
The simplest way to manage content delivery on Connect is using access controls. By default, content published is only available to the publisher. Publishers can update the access control list at any time.
Connect can be configured to restrict how widely publishers can share content. For example, an organization could require admin review before making content available to all users with or without login.
Versioning and Rollbacks
Normally users deploy content to Connect and then deploy updates by publishing to the same content endpoint. Updating in this way allows for automatic versioning, automatic rollback, instrumentation data tracking, and persistent logs and content settings. During updates Connect will gracefully handle user sessions across the old and new versions of the app.
Dev/Test/Prod
Sometimes teams will want a workflow for promoting content after various levels of testing. For example, a developer may want to deploy a shiny app for themselves while writing code, then deploy the app for others to test, and finally deploy the app for stakeholders. Deploying the same content to different endpoints opens the door for a variety of promotion workflows. Multiple app deployments can be supported through push button publishing or a Git branching strategy can be used.
Deploying to different endpoints is a strategy that can work on a single Connect server, or on distinct Connect servers that may live in different test and production environments.
Each content endpoint can have different access settings and a unique custom URL.
URL Swapping
We recommend sharing a custom content URL with users because it creates a safety net that allows for many different deployment techniques. For example, imagine a deployed app whose endpoint is content/123abc. It is possible to create a custom URL for stakeholders, https://connect.example.com/myapp. The application will be available at both URLs. By default only administrators can create custom URLs. It is possible to allow publishers to create custom URLs through a global Connect configuration.
Normally updates are made by publishing content to the same endpoint, content/123abc. Re-using the same endpoint enabled automatic versioning, consistent instrumentation data, and graceful rollbacks. However, there may be a reason to deploy a version of the app to an entirely different endpoint, content/456def. Reasons for using a new endpoint may include substantial application changes, migrations to a different content type, or maybe a disaster has broken the old endpoint. No matter the reason, it is possible to swap the custom URL myapp to point at this new endpoint, giving users access to the updated content without any downtime.
