Team Collaboration
Easily Work Together
A common challenge on teams is sharing and running code. If you’ve sat down to run a colleague’s code, only to spend hours installing and updating packages, you’re familiar with the pain points. Luckily, adopting any of the strategies for creating a reproducible environment will result in easier team collaboration.
Here, we’ll compare the Shared Baseline and the Snapshot and Restore strategies, with a special emphasis on how the two strategies can be used in collaborative settings. Before diving in to reproducible environments, it is critically important that teams master version control.
Strategy Recap
Shared Baseline: Administrators manage multiple version of R on a shared server. Each version of R is associated with a frozen repository, so that all users accessing the same R installation access the same packages. The frozen repository prevents users or admins from breaking packages when they add new packages, by preventing “side-affect upgrades”.
Snapshot and Restore: Using a tool like the
renv
package, users maintain an isolated project library and explicitly record the library’s content.
Each of these strategies is easily adapted for teams wishing to collaborate on shared code.
Snapshot and Restore for Collaboration
The snapshot and restore strategy is easily adapted for collaboration using a tool like the renv
package:
- The developer creates a
renv.lock
file usingrenv::snapshot()
. The lock file is committed alongside the application code into a version control system like Git. - The collaborator clones the Git repository into a new project. The
renv.lock
file is included. - The collaborator can use
renv::restore()
to recreate the necessary package environment for the project.
For more details, refer to the renv
vignette on collaboration.
Comparison
The shared baseline strategy requires initial work to create a shared development server, a frozen repository, and multiple R installations. Once this upfront work is complete, day to day collaboration is straightforward. This strategy is best suited for a team with strong R administrators and can help teams that need to on board new R users rapidly.
In contrast, the snapshot and restore strategy has minimal initial work, but requires vigilance during day to day development and collaboration. This strategy is best suited for power R users or cases where a shared development server is not possible.