Chapter 13 Deploy your application

Your deploys should be as boring, straightforward, and stress-free as possible.

How to Deploy Software - Zach Holman

Once your app is built, you are ready to deploy it! In other words, your software is now ready to be used by other users. There are two main ways to share your application and make it available to others: by creating a package and making it installable, or by sending it to a remote server. We will see in this part how you can do that using {golem} (Fay et al. 2020).

13.1 Before deployment Check-list

Here is a quick checklist of things to think about once your application is ready, and before sending it to production

  • devtools::check(), run from the command line, returns 0 errors, 0 warnings, 0 notes

  • The current version number is valid, i.e if the current app is an update, the version number has been bumped

  • Everything is fully documented

  • Test coverage is good, i.e you cover a sufficient amount of the code base, and these tests cover the core/strategic algorithms

  • It’s clear to everyone involved in the project who is the person to call if something goes wrong

  • It’s clear to everyone involved in the project what is the debugging process, how to communicate bugs to the developer team, and how long it will take to get changes fixed

  • (If relevant) The server it is deployed on has all the necessary software installed (Docker, Connect, {shiny} Server…) to make the application run

  • The server has all the system requirements needed (i.e the system libraries), and if not, they are installed with the application (if it’s dockerized)

  • The application, if deployed on a server, will be deployed on a port which will be accessible by the users

  • (If relevant) The environment variables from the production server are managed inside the application

  • (If relevant) The app is launched on the correct port, or at least this port can be configured via an environment variable

  • (If relevant) The server where the app is deployed have access to the data sources (database, API…)

  • If the app records data, there are backups for these data.

13.2 Sharing your app as a package

13.2.1 Install on your machine

A {shiny} application built with {golem} (Fay et al. 2020) is by definition an R package. This {shiny} App as a Package is also helpful when it comes to deploying your application: packages are designed to be shareable pieces of R code.

Before sending it to a remote server or sharing it to the world, the first step is testing if the package can be installed on your own computer. To do that, when you are in the project corresponding to the golem you built, you can call remotes::install_local() to install the application on your computer. Of course, if you are somewhere else on your machine, you can call remotes::install_local("path/to/app"). If you are using the RStudio IDE, you can also click on the Build tab, then click on the Install and Restart button.

This should restart your R session, and call library(yourpackagename). Then, try the run_app() function to check that the app can be launched.

13.2.2 Share as built package

A. Local build

Building an app as a package also means that this app can be bundled into an archive, and then shared, either as is or using a package repository like the CRAN.

To do that, you first need an bundled version of your app, which can be created using the build() function from {pkgbuild} (Wickham and Hester 2020) in the same working directory as your application. Calling this function will create a .tar.gz file that is called mygolem_0.0.1.tar.gz (of course with the name of your package). Once you have this tar.gz, you can send it to your favorite package repository.

You can also share the file as is with others. If you do so, they will have to install the app with remotes::install_local("path/to/tar.gz"), that will take care of doing a full installation of the app, including installing the required dependencies.
Then, they can do library(yourpackagename) and run_app() on their machine.

B. Send to a package repository

The upside of building the application {golem}, i.e as a package, is that you can share your application on a remote package manager, the more widely used for example on the CRAN like {dccvalidator} (Woo, Kauer, and Montgomery 2020), or on BioConductor like {spatialLIBD} (Collado-Torres, Maynard, and Jaffe 2020). But any other package manager will work: for example if the company uses RStudio Package Manager, your application can be installed here as any other package. If your application is open-source, the package structure also allows to install from GitHub, by using the remotes::install_github() function.53 For example, this is what you can do with {hexmake}, or {tidytuesday}: as they are open-source packages, they can be installed from GitHub. Then, once your application is installed as a package on the users’ machines, they can do library(yourpackagename) and run_app().

The advantage of this solution being that R users are familiar with package installation, so it makes using your application easier for them. Also, and we will see it in the next section, but making your application available as a standard R package makes it easier to deploy it: for example if your RStudio Connect is coupled with your RStudio Package Manager, the deployment file just have to contain one line launching the application.

Note that releasing to CRAN or BioConductor requires extra effort: you have to comply to a series of rules. But good news: as you have been following the best practices from this book, you should not have to put that much extra efforts!

Know more about releasing on CRAN:

13.3 Deploying Apps with {golem}

The other way to make your application available to others is by sending it to a remote server that can serve {shiny} applications. In other words, instead of having to install the application on their machines, they can crack open a web browser and navigate to the URL where the application is deployed. Deploying to a server is the solution of choice when you want to make your application available to a wide public: on a server, visitors do not have to have R installed on their computer, they do not have to install a package or launch it, they can just browse the application like any other web application. This solution is also a common choice in companies that have strict security requirements: the IT team might not be willing to let everyone install software on their machine, and sharing an application on a server allows them more control over who can access the application. For example, deploying on a server allows to use proxy, and to filter by IP: then, only a subset of people can have access to the application.

When using {golem}, you can open the dev/03_deploy.R and find the functions for server deployment. At the time of writing this book, there are two main ways to deploy a shiny app on a server:

  • RStudio’s solutions
  • A docker based solution

13.3.1 RStudio Environments

RStudio proposes three services to deploy {shiny} application:

  • shinyapps.io, an on-premise solution that can serve {shiny} application (freemium)

  • {shiny}-server, a software you have to install on your own server, and that can be used to deploy multiple applications (you can find either an open source or a professional edition)

  • RStudio connect, a server-based solution that can deploy {shiny} applications and markdown documents (and other kind of content), and that serves them as ordinary websites

Each of these platforms has its own function to create an app.R file that is to be used as a launch script of each platform.

  • golem::add_rstudioconnect_file()

  • golem::add_shinyappsio_file()

  • golem::add_shinyserver_file()

What these app.R files do is calling a pkgload::load_all() function, that will mimic the launch of your package, and then call the run_app() function from your packaged app. Note that if you need to configure the way your app is launched on these platforms (for example if you need to pass arguments to the run_app() function), you will have to edit this file.

Note that when using these functions, you will be able to use the “One click deploy” for these platforms: on the top right of these app.R, use the Blue Button to deploy to server.

Another way to deploy your {golem} based app to {shiny} server and to Connect is to link these two software to a local repository (for example an RStudio Package Manager), and then to only use mypackage::run_app() to the app.R.

13.3.2 Docker

Docker is an open source software used to build and deploy applications in containers. Docker has become an core solution in the DevOps world and a lot of server solution are based on it. See the “Strengthen” chapter for a more complete introduction to Docker.

You will find the function for creating a Dockerfile for your {golem} app inside the 03_deploy.R file, which contains a series of 3 functions:

  • golem::add_dockerfile()
  • golem::add_dockerfile_shinyproxy()
  • golem::add_dockerfile_heroku()

The first function creates a “generic” Dockerfile, in the sense that it is not specific to any platform, and would work out of the box for your local machine. The second one is meant for {shiny}Proxy, an open source solution for deploying containerized {shiny} applications, and the third for Heroku, an online service that can serve containerized applications (not specific to {shiny}).

Other platforms can run Docker containers, notably AWS and Google Cloud Engine. At the time of writing these lines, {golem} does not provide support for these environment, but that is on the ToDo list!

Note that the Dockerfile creation in {golem} tries to replicate your local environment as precisely as possible, notably by matching your R version, and the version of the packages you have installed on your machine. System requirements are also added when they are found on the sysreqs service from r-hub. Otherwise you might have to add them manually.

References

Collado-Torres, Leonardo, Kristen R. Maynard, and Andrew E. Jaffe. 2020. LIBD Visium Spatial Transcriptomics Human Pilot Data Inspector. https://doi.org/10.18129/B9.bioc.spatialLIBD.

Fay, Colin, Vincent Guyader, Sébastien Rochette, and Cervan Girard. 2020. Golem: A Framework for Robust Shiny Applications. https://github.com/ThinkR-open/golem.

Wickham, Hadley, and Jim Hester. 2020. Pkgbuild: Find Tools Needed to Build R Packages. https://github.com/r-lib/pkgbuild.

Woo, Kara, Nicole Kauer, and Kelsey Montgomery. 2020. Dccvalidator: Metadata Validation for Data Coordinating Centers.

  1. This is also true for any other Version Control system↩︎

ThinkR Website