Chapter 13 Deploy your application
Your deploys should be as boring, straightforward, and stress-free as possible.
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 notesThe 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 runThe 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.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.
This is also true for any other Version Control system↩︎