プログラム部とデータ部のレポジトリの分離

[NPoi]

改善詳細 / Details of Improvement

• プログラムを管理しているレポジトリに更新データがあるため、プログラムの更新があるたびにデータの更新がかかる恐れがあり、テストしにくい。

期待する見せ方・挙動 / Expected behavior

• データ部のみレポジトリを分けてサブモジュール化など。

動作環境・ブラウザ / Environment

• macOS / Windows / Linux / iOS / Android
• Chrome / Safari / Firefox / Edge / Internet Explorer

[taka1985]

これって、このissueみたいなことですか？
#208

[taka1985]

これが終わった後、#46 のissueをやる必要がある？これはお門違いでしょうか

[NPoi]

@taka1985 #208 は近いかも知れませんが、本Issueではデータの作り方の方法については別に述べていないので、近いとはいえ本質的には違うと思います。

単に、dataディレクトリ以下の日々更新されるデータをこちらのレポジトリで管理するのではなく、別レポジトリなどに管理をうつすことによって、管理コストを下げたいだけです。
日々のデータ更新だけでこのレポジトリのコミット数が増えていくのは違和感があります。このレポジトリのコミット数が増える場面は、機能の追加・改善・改修・削除などの場面であるべきだと。
このレポジトリでの作業的には .gitignoreに当該ディレクトリを登録するだけです。もちろん、その後の作業として、デプロイ時にデータのjson群をどこかからか取ってくる処理を書いたりする必要はありますが。

#46 は表示上の内容の管理であり、これはこちらのレポジトリで管理するものだと思います。

[taka1985]

@NPoi さん
別のレポジトリに移動して管理コストを下げる、というのが何に関しておっしゃっているのかは私にはわかりませんでした。
別レポジトリだから管理コストが下がる、と捉えるのか、それとも、
別レポジトリだからこちらのレポジトリとの一部情報の整合性をはかるコストが増える、と捉えるのか、人それぞれな気がしたからです。

.gitignoreに当該ディレクトリを登録するだけ

データのjson群をどこかから取得する、だと格納場所で一議論ありそうですね。
例えば、主で更新している人がいて、
その人が管理しやすい場所にdataディレクトリを移動させたい、というのであれば
そうするのがよい気がしました。
中心メンバー側にてご検討いただければと思いますので、何卒よろしくお願いいたします。

[NPoi]

@taka1985

別のレポジトリに移動して管理コストを下げる

たとえば、プログラムの変更履歴を見たいのに、現状データの変更履歴が大量に混ざっていて、はじめてソースコードを見る人はまずデータ変更の履歴を除外する必要があるわけです。
git blameなどを使えば軽減はできますが、レポジトリとしての責務が明確ではないというのが問題だと思います。

データのjson群をどこかから取得する、だと格納場所で一議論ありそうですね。

現状だとすでに、
https://github.com/CodeForNiigata/covid19-data-niigata/tree/master/dist
にCIで自動的にデータは上がってきていますで、デプロイ時ここからデータを取得すればいいだけという認識です。
こちらではすでにデータの履歴管理も出来ていますし、であれば、わざわざcovid19レポジトリに置く必要はないでしょう。

手動で更新が必要な場合でも、同場所で管理した方がいいのではと思います。

[taka1985]

@NPoi さん

master/distにてCIデータがある云々

そうですね。
こちらを見れば、大方のjsonデータは良さそうですね。

手動で更新が必要な場合でも、同場所で管理した方がいいのではと思います

⇒同場所とは、master/distのことかと思うのですが、
　確かCIで作ったデータがmaster/distに更新されるはずなので、手動更新をしても上書きされることを意味する気がするのですが...(ひょっとして、私が本題から外れてるだけ？）

[NPoi]

同場所とは、master/distのことかと思うのですが、
　確かCIで作ったデータがmaster/distに更新されるはずなので、手動更新をしても上書きされることを意味する気がするのですが...(ひょっとして、私が本題から外れてるだけ？）

それはそのとおりで、翌日19時には書き換わります。
ただ、当日CIに失敗した（元の文書の形が変わってしまってうまくいかないことは往々にしてよくあります…）場合は手動書き換えが必要で、その際はその日に限りそういう対応になる、ということです。
翌日、そのままうまくいけばうまくいきますが（一日だけ元データがおかしい、も往々にしてよくあることです……）、だめであれば恒久対応として、CI側のプログラムも書き換えることになります。

[taka1985]

ナルホド