I'm interested in other people's opinions on this matter.
If you're part of a company that creates and maintains multiple shiny apps, do you host them all on the same git repo, or each one separately?
Regardless of the deployment solution.
1 Like
I was discussing this issue with some clients just this week. One of the things we have been working on is wrapping up each application into its own package. It makes it easy to then document functions which are bespoke to a single app, and also to have a clear set of dependencies and dependency-management for each app. We have also talked about creating a "wrapper" package to contain code that individual apps can depend on (e.g. custom-formats applied to DT tables, or similar), and that itself can group together a collection of apps in a similar way to how tidyverse collects a number of individual packages together.
My view was that when doing this it's better to have 1 repository per app (or package in our case). Whilst this does create a bit of overhead managing multiple repositories, I think it makes it easier to manage the code for 1 particular app/package.
It also means that if a user is interested in the code for 1 app, they can easily get just what is relevant to them, without having to worry about code for other apps/packages in the same space (it keeps the cognitive burden a bit lower for users trying to understand just one component).
This also makes it a bit easier to manage a single app/package versions over time, branch the code etc etc, all the usual good things that come with a version control and which might get complicated if several large applications were all bundled in to the same repository.
I would extend this logic to most things an organisation does - 1 repository per tool, 1 repository per project, 1 repository per... etc etc. I suppose in a way I'm extending the advice Hadley gives for packages (make them do one thing, and do it well) to repositories: one repository for one thing, that one thing is clear and easy to understand.
4 Likes