问题描述
我们有一个 linux (Ubuntu 14.10) 生产服务器，以及我们编写的许多 R 脚本，我们希望在它上面运行，这些脚本将收集来自 API 或网页抓取的数据.然后数据将写入 CSV 文件.
We have a linux (Ubuntu 14.10) production server, and a number of R scripts we have written that we want to run on it that will collect data either from APIs or web scraping. The data will then be written to CSV files.
我的背景是 SQL Server/Fortran，在生产环境中应该遵循非常具体的最佳实践.一些突出的是:-
My background is SQL Server/Fortran and there are very specific best practices that should be followed with regard to production environments. Some salient ones are:-
- 生产环境在版本控制方面应该是稳定的，无论是从代码的角度来看，还是安装的应用程序、操作系统等.
- 对代码/应用程序/操作系统的更改应在单独的环境中或以受控且可撤销的方式进行.如果存在第二个环境，则可以执行并行执行以测试系统更改的可能性.
- (在很大程度上)，开发人员无法更改生产环境.
我的问题是:如何确保与我的 R 代码关联的包保持一致和不变，直到我选择更新它们?
My question is this: How can I ensure that the packages associated with my R code remain consistent and unchanging, until I choose to update them?
推荐答案
你可以使用 Docker；我们的 Rocker 项目有几个合适的容器可以启动.
You could use Docker; our Rocker project has a few suitable containers to start.
否则就使用基本的 Unix sys.admining:
Otherwise just use basic Unix sys.admining:
- 如果您不想更改 R 的包目录，请将它们设为只读
- 也许使用 HPC 人员的一些技巧，并使用模块"(即符号链接层或 PATH 设置)使某些路径和目录可见或不可见
总的来说，关于可重复研究的任务视图有一些进一步的指针.您可以在每次生产运行中记录使用的版本，并且您可以设置运行，以便将版本与预期版本进行比较.
In general, the Task View on Reproducible Research has some further pointers. You can document in each production run what versions were used, and you can set up runs in such a way that versions can be compared to expectated versions.
但这些都不是 R 真正的问题——这些都是部署的元"问题.
But none of this is genuine to R -- these are all "Meta" questions for deployment.
这篇关于在生产中运行的最佳实践 R 脚本 - 包版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！