3. Publishing Content

In this section, you will learn:

How to publish content to Connect
Content promotion strategies
How Connect manages R and Python environments for pieces of content

Publishing content

There are three ways to publish content to Connect.

Push-button from the RStudio IDE or Jupyter Notebooks.
Git-backed with Connect polling git repositories and redeploying content on changes.
Programmatic via the Connect API or the rsconnect-python CLI.

Push-button publishing

This publishing method is helpful for users who want to publish content directly from their development environment. A button is available in the RStudio IDE and Jupyter Notebooks setup with the Posit Jupyter extension. When push-button deploying use the vars setting to add environmental variables or secrets.

In other development environments, users can utilize the rsconnect-python CLI tool for one-step Python deployment of Python applications and APIs.

Git-backed publishing

Instead of a user pushing content, Connect can be set up to periodically poll git repositories, deploying the latest version of the content upon changes to a branch. A user must create and include a manifest.json file in the git repository. The manifest.json file tracks the content type (R Markdown, Shiny application, FastAPI, etc.), the version of R/Python, and package dependencies.

The frequency in which the git polling occurs is controlled by the PollingFrequency setting, which is 15 minutes by default.

Multiple git operations can be performed on the server concurrently. In the git section of the configuration Concurrency the default is set to 2, meaning only two pieces of content will be deployed in parallel. If you expect content to change often and around the same time, increase this setting.

Public repositories

Publicly-accessible source repositories may be configured by any user with a “publisher” role.

Private repositories

Private source repositories require credentials to be specified in the Connect configuration in the GitCredential section; an example is below.

[GitCredential]
Host = github.com
Username = accountName
Password = <encrypted-string>
Protocol = https

Programmatic publishing

Content can be pushed to the Connect server from various sources by utilizing the Connect API. This pattern is beneficial in a CI/CD pipeline where tests and other pre-deployment activities can occur before the content is deployed.

A few API calls are required to deploy content to Connect, including creating, uploading, and deploying a bundle. The rsconnect-python CLI also can be used to orchestrate the API components needed.

To learn more about deploying content using the Connect API refer to the Connect API Cookbook Deploying Content Section.

Code promotion strategies

When developing content, it is often advantageous to have a strategy for managing how content is tested and put into production. For example, a developer may want to deploy a Shiny app for themselves while writing code, deploy the app for others to test, and finally deploy it for other stakeholders.

Flow chart of code promotion using push-button, git or programmatic deployment on a single server. — Code promotion methods on a single Connect server

Flow chart of code promotion using push-button, git or programmatic deployment on multiple servers. — Code promotion methods on multiple Connect servers

All three publishing methods can be used in the strategies outlined above. Each application has a unique URL to differentiate a test from a production deployment in the single server case. In the multiple server case test applications would be deployed on a dedicated test Connect server, whereas production applications would be deployed on a dedicated production Connect server.

Note

When setting up a git-backed or programmatic deployment, utilizing a separate development dev branch and production main branch in git is often helpful. This way, a developer can push changes to the dev branch and have the content redeployed for testing without affecting the production content, which watches the main branch.

Environment management

Each time a piece of content is published to Connect, an environment including the version of R or Python and package dependencies must be recreated to run successfully.

R and Python version matching

The process of matching R Versions and Python Versions is documented in the Administrator Guide linked. In brief, Connect attempts to find an R or Python installation appropriate for your content.

For R, Connect uses the “nearest” approach by default for version matching, which can be configured in the R configuration section VersionMatching.

For Python, Connect uses the “major-minor” approach by default for version matching, which can be configured in the Python configuration section VersionMatching.

Package management

R content

Posit Connect installs R package dependencies of Shiny applications, Plumber APIs, R Markdown documents, and Quarto documents when the content is deployed. In the RStudio IDE, rsconnect and packrat are used to identify the target source code and enumerate its dependencies. Then when a bundle is pushed to Connect, packrat is used to install the identified package dependencies.

Each package version is shared across content on the server by a cache. The packrat package cache allows multiple versions of a package to exist on a system. Distinct versions of packages are kept isolated from each other.

Python content

Posit Connect installs Python package dependencies of FastAPI, Flask, Jupyter notebooks, Dash, Bokeh, Streamlit, and R projects, including Python, when the content is deployed. When deploying content, a requirements.txt file is part of the bundle sent to Connect (if one does not exist, then pip freeze will be executed). Then when a bundle is pushed to Connect, venv and pip are used to install the identified package dependencies

Posit Connect maintains a cache of Python environments to enable faster deployments. New environments are created as needed based on the list of package dependencies received in the bundle and the python version in use. Subsequent deployments with the same dependencies will reuse the previously-built environment.

Package compilation

Some packages contain C and C++ code which needs to be compiled during package installation if packages are installed from source. CompilationConcurrency in the server section of the configuration is set to 1 by default. If you anticipate source installations of many packages and there are system resources to support concurrency, consider increasing this number.

Note

If R content is utilizing packages installed from either Posit Public Package Manager or Posit Package Manager, then most packages will install from binary instead of source. In these cases, the need for compilation will be much lower than if all packages are installed from source.

Private packages

R

Packages available on CRAN, a private package repository, or a public GitHub repository are automatically downloaded and built when an application is deployed. Posit Connect cannot automatically obtain packages from private GitHub repositories.

Python

If you have a Python package repository for your own Python packages, or have a PyPI mirror inside your firewall, you can configure Posit Connect to use that package repository when installing packages by editing pip.conf. More details are provided in the Administrator Guide.

Exercise

Tip

🚀 Launch the exercise environment!

In the exercise environment you will get experience:

Deploying R and Python content from git repositories
Observing how Connect deploys R and Python content
Modifying git deployment configuration settings