Publishing Methods for RStudio Connect

There are three ways to publish content to RStudio Connect:

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.

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 the code base and deployed content are always in sync.

Connect can publish content from private Git repositories. Add a service account to the repositories, and add the credentials of this service account to the RStudio Connect configuration file, an action that requires the server administrator.

Git-backed deployment does not support running tests prior to deployment. To take advantage of continuous integration workflows, employ API-backed publishing, as described below.

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. A benefit of this method is the ability to add tests and other pre-deployment activities commonly found in CI/CD pipelines. 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:

A few examples:

• Official API cookbooks
• Example with GitHub Actions
• Example with Azure Pipelines
• Example with GitLab CI/CD
• Example with Jenkins

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.

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.