Asset Deployment Approaches

A high level view of how to deploy assets into Production. In this context, assets refer to artifacts that can be published to RStudio Connect. These are suggested approaches. They are meant to help admins create an internal solution that fits their company’s environment best.

For an overview of different methods for publishing content as an end-user, refer to the section on publishing methods for RStudio Connect.

It is important to note the order in which these approaches are presented in. They are not in a good-better-best order. They are ordered by their level of complexity. Additionally, each approach builds up on the previous one. The approach that fits best will have to match the company’s current IT processes and requirements. Over time, the selected approach may need to change. The change could be triggered by a growing audience, more frequent deployment of assets, or an increase of technical and process maturity.

Restrict access to asset

Background

The simplest way to deploy is to provide control over when the target audience can use the asset. Typically, the R developer collaborates with a business user in the development of the asset. The business user provides feedback about the content of the asset. In most cases, it is unrealistic to expect the business user to run R personally. The best way for them to test the asset is to access a published copy.

Approach

The R developer publishes the draft of the asset to RStudio Connect. In RStudio Connect, the R developer limits access rights to only the business user. After the business user reviews the asset, and if there are no changes, the R developer (publisher) can open access to the rest of the intended audience. If there are changes, the R developer makes the changes in the code, republishes the asset, and requests another review from the business user.

This approach fits best with smaller companies. In larger organizations, this approach works for data teams who have full control over their own servers.

Pros

  • Provides the lowest barrier for the R developer to create and deploy new assets
  • Gives the R developer full control over when the assets are published

Cons

  • An unreleased asset may consume lots of resources. Testing may affect other assets currently in Production (See Multiple Environments if this is the only Con that is of concern)
  • The approach may not satisfy current IT or security requirements

Multiple environments

Background

The R developer has access to two environments. A development, or sandbox, server and a separate Production server.

Approach

The business user has access to test the asset in a development server. When the asset is approved, the R developer publishes the same asset to a Production server. There, the asset is setup for the intended audience to access.

This approach fits will with small to medium organizations. Usage of the production server is heavy enough that it is important to isolate assets that are in development from assets that the production audience is dependent upon.

Pros

  • Very low barrier for the R developer to create and deploy new assets
  • Gives the R developer full control over the timing for publication
  • Isolates tests of new assets to just the development server. No assets in Production will be affected by tests of assets that consume lots of resources

Cons

  • The approach may not satisfy current IT or security requirements, it provides constraints around allowing developers to publish to production

Request deployment

Background

The organization has requirements that only the IT team is able to make changes to Production environments.

Approach

The R developer has access to publish only to a development server. This is where the business user will approve the content. The R developer asks the IT team to publish the approved content into the Production server. The IT team takes the R developer’s code and publishes the asset into Production.

This approach fits best in medium to large organizations. It works best when the IT and R development team work closely together. Another success factor is the frequency of new assets and updates to assets. At a low frequency, it is easy for the IT team to update the assets manually. At a higher frequency, that may become a challenge. In that case, the following approach may be a better option.

Pros

  • Likely meets IT and security requirements
  • More stable process for deploying, and maintaining assets

Cons

  • Necessary intra-team collaboration may not be available at a given organization
  • Longer time between approval and publishing to Production

Continuous integration

Background

The organization currently has a Continuous Integration process and infrastructure. The desire is to use such infrastructure to automate the deployment of the asset into RStudio Connect.

At this level of maturity, R code review is a typical secondary requirement. The R code will be reviewed and approved by the appropriate R developers before triggering the submission to Production.

Approach

The asset is tested and approved by the business users. The R developer submits the new code for review and approval. At the time the code has received all of the required approvals, the code is merged into the master. At this time, a new job is triggered that publishes the asset into the Production server.

Pros

  • Most sophisticated and safe way to publish and maintain assets
  • Provides multiple check points to ensure that the asset works as expected
  • Most likely to meet IT and security requirements
  • Also quicker than the manual approach above, potentially requires less inter-team communication as part of daily work

Cons

  • Requires an existing Continuous Integration (CI) process and infrastructure
  • Requires integration architects that know how to add new applications to the CI infrastructure
  • New integration may require a long time to plan and setup

A deeper look into this approach is available in the Programmatic Deployment with Content Management APIs article.