最近、私はいくつかの非常によく似たShinyアプリケーションをさまざまなクライアント向けに作成し、shinyapps.ioでそれらをホストしています。さまざまなバージョンのShinyアプリケーションを維持するためのワークフロー
各アプリのタイトル、データ、ブランドの違いなどがありますが、それ以外のコードは非常に似ています。
これらのアプリのメンテナンスに問題があります。バグを見つけて修正するときは、現在5つの異なるアプリを使い、毎回変更を加えなければなりません。
誰もこれを処理する方法に関する良い提案はありますか？ Gitブランチ？ 1つのアプリを持ち、異なるデータをアップロードするのが最善の解決策であることはわかっていますが、残念ながらそれは不可能です。
私はshinyapps.ioを使い続けたいと思っていますが、私のワークフローをより良くするには、他の場所にアプリをホストすることができます。私はコメントに書いたように
shinyModules()がお手伝いします：通常の関数は、コードを繰り返すにあるようhttps://shiny.rstudio.com/articles/modules.html
シャイニーモジュールは、光沢のある機能にあります。
それともが異なり、それを置くために：
をドキュメントがあちこちで少し複雑であるため、私は簡単な例をここに書いた： Create a reactive function outside the shiny app。
すべての光沢のあるモジュールをファイルmodules.Rに保存し、モジュールをロードする各アプリケーション（source("../modules.R"）にglobal.Rスクリプトを追加することができます。その後、modules.R内の機能を更新するだけです。その構造の変化には、最初はしばらく時間がかかるかもしれません。しかし、私は長期的には、より複雑なアプリを支払うと考えています。
Adam Spannbauerのコメントのように、私はアプリに必要なほとんどのコードを含むライブラリを作成しました。
これは完璧ではありません。私はまだいくつかの複製を持っており、GitHub上でライブラリを持っていなければならないので、shinyapps.ioと一緒に使えるようにしなければなりません。しかし、それは私が以前行っていたことを大きく改善しています。
もしそれらが同じルーチンを共有している場合は、それらのルーチンをパッケージに束ねてそこから共有ルーチンを維持することができます –
光沢のあるモジュールのようなサウンドがここで役立ちます：https://shiny.rstudio.com/articles/modules.html 。コードを何回か使用しているように見えますが、反応関数を光沢のある外に定義してそこで更新し、関連するアプリで 'callModule（）'を使って呼び出すことができます。私はここで最小の例を書きました：https://stackoverflow.com/questions/43976128/create-a-reactive-function-outside-the-shiny-app/43976516#43976516。 – BigDataScientist
Git分岐が役立つかもしれません。共通の機能を備えたセントラルブランチを持つことができ、各アプリごとに分岐することができます。一般的なバグ修正は 'master'で起こり、他のブランチはそれに同期できます。 –