Skip to content

Publishing Methods for RStudio Connect#

There are three ways to publish content to RStudio Connect:

deployment-spectrum

Push button publishing#

This publishing method is useful for data scientists who want to publish content directly from their development environment.

A reproducible bundle with application code and dependencies is automatically created during push button publishing. The bundle is deployed to RStudio Connect where the data scientist can finalize publication settings.

Push button publishing is available in the RStudio IDE and Jupyter Notebooks. While there currently is no "button" to deploy other types of Python content, a Python CLI tool can be used for one-step Python deployment of Python applications and APIs.

Git-backed publishing#

Git-backed publishing is useful as a lightweight continuous deployment solution when data scientists want to use Git for version control.

git-backed-publishing

To deploy content directly from Git, data scientists configure Connect to track a particular branch and directory in a Git repository. Once setup, Connect will poll the repository for changes and automatically deploy updates, so updating content is as easy as making commits or merges to the branch Connect is watching.

API-backed publishing#

Deploying content with the RStudio Connect API is the most flexible deployment method but also requires the most setup. In API-backed publishing, an external CI/CD system pushes content updates to RStudio Connect using the RStudio Connect Server API. The Connect Server API allows teams to fully automate most actions that would otherwise be done manually in the Connect web interface such as:

  • deploying content
  • adding users to content
  • customizing runtime settings

The API endpoints can be called directly or teams can integrate client packages like rsconnect-python or connnectapi into their CI/CD systems. An example workflow might include these steps:

deployment-steps

A few helpful examples:

Publishing Workflows for RStudio Connect#

Using the publishing methods outlined above, 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 RStudio 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.

rollback

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.

git-branching

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.

promotion

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.

content-url