自動アップデート機能

[uzulla]

自動的にアップデートする仕組みを実装する

工程

• お知らせ機能
• メンテバージョンがあげられる機能（バグ修正のみ（つまり、app以下にファイルを置き換えるだけ）、テンプレやDB等に変更が不要）
• マイナーバージョンがあげられる機能（非破壊な機能追加のみ、DBはカラム追加のみ、テンプレ再生成は必要な範囲か？）
• メジャーバージョンがあげられる機能（コンフィグファイルの設計や、DBでカラム削除まであるようなスキーマ変更あり）

検討課題

• 自動更新ができる「範囲」について
  • メンテバージョンアップ
  • マイナーバージョンアップ
  • メジャーバージョンアップ
  • どこまで「自動」でできることを目指すか？
• ロールバックは必須か？
• 互換性確認
  • プラグイン的なものが始まると大変
• コード更新方法
  • releaseのtar ballを展開する
    • アップデート中は「壊れた」状態になりがち
    • 「メンテナンス中」表示機能
  • サーバー上でdeployer(等)のデプロイツールを自己実行
    • レンサバと相性が悪い
    • ストレージを多く消費する
  • ブログアプリとインスタンスを分離し、composer update する
• DBマイグレーション
  • 素朴なマイグレーションSQLを同梱
  • phinxなどのマイグレーションツールの導入
  • 実行時間制限で失敗すると壊れる
  • DB設計を変更し、「カラムの追加」がほとんど発生しない設計に変更する
• （現在の実装に存在する）CSSなど、依存する生成ファイルの類をどうするか？
  • 毎回再生成？
• アップデートのトリガーは？
  • 管理画面で実行
  • 新バージョンが存在する事をユーザーに通知する仕組み
  • ユーザーアクセス（で、ランダムに確認させる？）
  • cron
• 間隔がリープしたバージョンアップのテストをどうするか？
  • 「1.0.0から1.29.9 までバージョンアップできる」ことをどうテストするか？
  • あるいは順番にしかあたらないようにするか？

[fc2dev]

@uzulla

ロールバック
アップデートを開始する前にバックアップを取得しておき、
いざというときに戻せる様には（データを用意）しておく必要はあります。
ただし、UIとしてロールバック自体ができる機能の提供は今のところ必須ではありません。

互換性確認
アップデート機能の実装が複雑になりすぎない様にするため、
リープしたバージョンについては、順番にアップデートを適用していただくことを
原則としていただいて構いません。

あくまで本体をアップデートするための機能として今回は開発をし、
新しいバージョンとの互換性を定義するのはプラグインの責任とし、切り離して考えても構いません。
プラグインという名前の機能はあるにしても、他のOSSでのプラグインの機能とは異なるものなので、
プラグイン機能の提供の際に改めて検討をしたいです。

DBマイグレーション
DB設計については、テーブルが細分化されており、
大きなサイズのテーブルだとアップデートの最中にタイムアウトが発生してしまう懸念があります。
機能追加のことを考えると、
WordPressの様にpostsテーブルに投稿、コメント、プラグインの書き込み、メニュー...etcが
全て入っている様な構成にする必要はあるかもしれません。

生成するファイル
CSSやテンプレートなど生成する必要があるファイルは毎回再生成する方向にしていただきたいです。
その場合、再生成されるファイルについては更新されることは注意書きとして追記する必要がある他、
再生成の影響を受けずに該当箇所を変更する方法を明記しておく必要があります。

アップデートのトリガー
管理画面で実行すること、コマンドラインから実行できる　２種類を提供するものとし、
新しいバージョンがある場合はユーザーに管理画面上で通知する様にします。

メールで通知ができる場合は、ユーザーアクセスを元にランダムにチェック処理を入れ、
通知する機能があるとなお良いと考えています。

[uzulla]

@fc2dev

要件承知しました。

最初から全機能を実装するのはむずかしいので、最初は「バグ修正パッチが当たる」程度の自動アップデートを実現し、できる範囲を広げていく方が良いかもしれませんがどうでしょうか。

たとえばですが…

• 新バージョン存在の通知機能（管理画面にて）
• メンテバージョンがあげられる機能（バグ修正のみ（つまり、app以下にファイルを置き換えるだけ）、テンプレやDB等に変更が不要）
• マイナーバージョンがあげられる機能（非破壊な機能追加のみ、DBはカラム追加のみ、テンプレ再生成は必要な範囲か？）
• メジャーバージョンがあげられる機能（コンフィグファイルの設計や、DBでカラム削除まであるようなスキーマ変更あり）

といったロードマップが考えられます（もうすこし、細分化するかもしれませんが）
検討してみます。

WordPressの様にpostsテーブルに投稿、コメント、プラグインの書き込み、メニュー...etcが
全て入っている様な構成にする必要はあるかもしれません。

「なんでもはいるKVS的なテーブルを用意して、そこから読む」というWPの設計はたしかに変更に強いのですが、クエリが増えるので速度が落ちがちなデメリットがあります。
FC2ブログは速度をウリにしていた所があったと記憶しているので、多少折り合いが必要かもしれません。

いずれにせよ、今の設計からかなりドラスティックな設計変更になるかと思います。
PSR-4化をしつつ、すこし検討したいと思います。
（DBマイグレーション機能の実装は、すこし時間がかかるかと思います）

[fc2dev]

@uzulla

確かに、風呂敷を広げすぎても検討内容が増えてしまうと思いますので、
ご提案の通り「バグ修正パッチが当たる」ことから広げていただければと思います。

設計については、レガシーなものは止むを得ないと割り切り、
上にキャッシュのための層を被せ、単純なHTMLの出力・変数の置換程度ができる様にする　
が　FC2ブログの実際のシステム構成になります。

[uzulla]

検討中の案ですが、当座の課題として以下があります

• ライブラリ群（Composerで入るもの）をどうするか
• テストファイルなど同梱不要なものがある（とはいえ、入れても構わない）

と考えております。

その上で、現在はapp publicのみで動作するようにはしておりますので、以下を検討しています

• composer install した状態のappとpublicを作成し、ZIPにしてReleaseファイルとして登録する（composerがわからないユーザーにもよいと思う）
• アップデートはReleaseを監視し、zipをDLして取得する
• app更新は、一旦別名で解凍し、rename差し替え。
  • 設定ファイルはこの時に決め打ちでコピー（か移動）する
• publicは上書き展開
• tempやuploadのファイルディレクトリは「移動」する
  • 安全を考えるとコピーしたいが、データ量が大きくなると厳しいので
• vendor以下にはcomposer installしたファイルがはいるが、基本配布OKなライブラリしか採用予定がない
• READMEをapp以下にも置く（これはビルド時にコピーすれば良いだけなので特に問題なさそう）

検討中の課題としては

• public以下については上書きしかできないので、「ファイルを消したい」時にどうするか（ elrte（WYSIWYGエディタ） 添付のファイルに問題がある。 #120 などのようなケース）
  • 上書きする時に、ユーザーのファイルを上書きするのがこわいので、public以下のファイル再配置をしたほうが良いかもしれない
  • （そもそもユーザーは自分でJSをアップロードなどしないということにして毎回初期化する？）
• ロールバックをどうするか
• DBマイグレーションは、まだよい案がない。post-script的なものをつくる？
• 面倒なので、zip生成はCI化する必要はあると思う（release ブランチをつくるか、リリースタグ（vX.X.X）を監視？）.

環境依存になるが、できれば楽なこととして

• Symlinkを使える環境のみサポートする（今もWindows 環境では動作確認していないですし、Linuxにかぎればsymlinkがつかえるのでtempやuploadの移動などの危険な処理が不要となる）

となっています。

---

Releaseの監視は、Github のAPIを叩くことでどうにかできるかと思います。

curl https://api.github.com/repos/org/repo/releases|jq .で、assetsがとれることを確認しました。

リリースノートも書けます

[fc2dev]

@uzulla

本件、承知しました。進めていただきたいです。
・Linux環境での利用を想定しているため、symlinkを前提にしていただいても問題ありません。
・システムが利用するJS類とエンドユーザーが利用するJS類は明示的にパスを分けて、
このパス以下はアップデートのたびに初期化されます　と前提をつけることで対応いただいて問題ありません。
・ロールバックはsymlink方式を採用すると幾分かは実装しやすくなるのではないかと考えています。
・DBマイグレーション実装自体が複雑になるのであれば、
極力テーブルを追加するだけの対応で済ませる　など一定の前提条件をつけていただく形でも問題ありません。

[uzulla]

app(vendorを含む), publicのみの配布で動作を確認した。
配布携帯としてユーザーが手元でcomposer installしてほしいが、難易度が高いと思われるので同梱することになりそう。

[uzulla]

@fc2dev

現在CIやお知らせ機能（たとえばGithub siteをつくり、そこにRSSを置くとか、Githubのリリース（タグ）機能を流用するとか）、配布zipを（Githubの）releaseに添付するような機能の実装をすすめておりますが、
私は本レポジトリにコミット・マージ権限がないため、CI(GH Actions)をさわりはじめると作業の待ちコストが一層高くなると考えています。（他にも、GH Pagesの設定や、Actionsの設定などもある）

私のforkレポジトリ内だけでコミットして開発していけばこちらのrepoには影響ありませんが、都度PRをつくっていくスタイルからは変わらざるをえないため、どのようにすべきか悩んでいます。

コミット権は切れないのかなと考えておりますが、このあたり、なんらかございますでしょうか？
アクティブに開発をすすめるなら、PRを一個一個見ていただかないで、まとめてPRを通常のやり方にしてよいでしょうか？
（実際、かなりきびしくなった時にはこちらでマージして、まとめたPRをおくらせていただきましたが）

[uzulla]

#233 インストーラー機能
を実装し、インストーラーを足がかりに実装することを現在検討しています。

[uzulla]

バージョン情報をどうやって保持するか検討中…

• app/version みたいなファイルをおき、中にタグと同じ v1.1.1みたいなものを記述したい
• しかし、手作業だとミスをしそうなので、CIにしたい
• fc2blog_dist.zipの生成をタグ打ちのCIでまわし、その時に生成して入れる？
• (リリースタグを打つ流れをまだ決めていない ref )

$ git rev-parse HEAD
41eb4d1e4344b7d140fda15f6c893a9a1fbe98a4
$ git tag -l --contains ca86f4e86a892c801720688a8bc8d0c9a0e3aff6
v0.0.1

$ git tag -l --contains `git rev-parse HEAD`
v0.0.1
or
$ git tag -l --contains `git show -s --format=%H`
v0.0.1

[uzulla]

[uzulla]

DB操作のない(ファイル更新のみの)バージョンアップをおこなえるようになった。

https://github.com/uzulla/fc2blog/tree/issue39/update-feature

（が、現時点では参照先レポジトリは uzulla/fc2blog、本番となる fc2blog/blog におけるタグ打ちが必要)

[uzulla]

DBマイグレーション機能

• tickを保持するテーブルを用意する

  • tickは単純インクリメントな整数
  • スキップ許可に「したい」。
  • TickとMigrationファイル群を突き合わせると今と、過去のギャップがリストにできるので順番に当てられる

• マイグレーションはphpで書く、phpならなんでも書ける

  • alterや、必要ならカラムの変換はここでやる
  • 追っかけパッチもできる、たとえば、index追加とか
  • 自己で、tickが自分の一つ前であることを確認するなどもできる

• 状態やマイグレーション一覧や適用をする親クラス（ライブラリ）を用意する

  • マイグレーションファイルはその子クラス（あるいはTraitを読み込み）
  • 命名規則は\Fc2Blog\Migration\Db\Tick123_WhatHow.php

• パージは(やれば可能だが)当初考えない

• テーブル操作はコピー、リネームして操作してリネーム戻しの予定

  • おおげさかもしれない
  • その時に完全無停止でははない（短時間ではあるが）
  • 「バックアップを事前にせよ」で、完璧な強靭性はめざさない

• ダウンは書かない（むずかしいので）

• AlterやCreate Table権限は必須だし、必ずあるだろうが、リネームやDROPのpermissonが無いケースとかあるだろうか？

• 現行のスキーマにも忘れずにtickをふる。

• 現在のバージョンアップコードに安全に差し込めるのか確認する

  • デプロイしたあとのファイルなので、ロードがどうなるかあやしい（__DIR__がどこを指すのか問題）
  • 怖いが一回リダイレクトを入れるしかない？

• マイグレーション中にサイトを止める機能？

  • サイトアクセスされると困るかもしれない（コメントとか）
  • ユーザー側画面だけでも止められれば嬉しそうだが、とりあえずストレッチゴール