Sakura: リリース運用手順 たたき台

[KENCHjp]

インストーラーまでは自動で作成できるのが確認できたので、リリースの段取りというか手順を空想してみました。

以下、運用イメージ書きますができるかどうかは全く検証できていません。

１）リリース対象のコミットを決定する
　・Issues等で対象コミットとリリース時のバージョン番号決定。
　　対象コミット決めればバージョン番号は自ずと決定？

２）対象のコミットに対してreleaseを作成する。
　・出来たらUIでトリガーを引きたい。Tag付をGitHub上でできる？
　・もしかしたら、appveyorの画面等でビルド番号等を指定して、releaseを作成すると同時にtag付け実施？
　・Tag名は、「2.a.b.nnn」でnnnはビルド番号か「2.a.b.0」固定とするか。自動であれば前者？
　・自動releaseしたら、いったんPre-releaseにして、動作確認したらPreを取るとか。

３）関連Webの修正
　・https://sakura-editor.github.io/
　　こっちは自動更新する？
　・https://osdn.net/projects/sakura-editor/
　　こっちはフォーラムにお知らせを掲載程度？
　・その他つぶやく？

これ出来たらコミッター外の人でもできる手順書まで仕上げられたらいいなと思っております。

[KENCHjp]

ちなみにですがGitHubはうちの会社でもこの間までアク禁（Proxy でフィルタ）でして、
いまでも企業系はアク禁にしてるときろもあるかと思うのでリリースバイナリを、
OSDNにコピー置く価値はあるのかなともってます。
その場合のOSDNのリリースアップロードは手動でもいいかなと。
窓の杜とかでダウンロードできるようになってもいいかなとおもうのですが、
公式以外を嫌う人もいるかなと。

[kobake]

アク禁

OSDN, 窓の杜, Vector, 必要であればどこかしらにコピー置くのはアリだと思います。
メンテナンスめんどくさいと思うので、GitHub Releases を中継するプロキシCGIをどこかに配置するとかでも良いかなと思ったりもしてます。

[kobake]

自分は以下のような感じで考えています。いくつか手動対応が挟まるので自動化できるのが理想ですが、最初から全部理想の仕組みを作り上げることは考えてないです。コスパの問題として。

• (1) 任意のタイミングで master 最新のものをリリース可とみなして良いか皆の決を採る
• (2) リリースバージョン番号を考えて決める
• (3) 決まったリリースバージョン番号を摘要するコミットを作って積む (PR を作る)
• (4) (3) の PR を精査し、問題なければマージ
• (5) (4) のマージコミットに対してタグを打つ
• (6) (5) でタグを打たれたコミットに紐づく AppVeyor バイナリを GitHub Releases にアップロード (正式公開完了)
• (7) (6) でアップロードされたバイナリが AppVeyor のものと同一であるかどうか、アップロード者以外の人のほうでも検証 (正式公開内容物のダブルチェック)
• (8) Web 更新は追って手動対応

ちょっと雑な書き方になってしまってますが、段取りに特に迷いは無いです。
ご意見あればください。＞all

[m-tmatma]

(7) (6) でアップロードされたバイナリが AppVeyor のものと同一であるかどうか、アップロード者以外の人のほうでも検証 (正式公開内容物のダブルチェック)

検証作業を容易にするために以下のようにしてはいかがでしょうか?

• appveyor で自動的に成果物に対して自動的にsha256 を計算して成果物に含める。
• GitHub Releases の sha256 と AppVeyor の sha256 が同じかを比較する。

(8) Web 更新は追って手動対応

Web サイトの更新も PR を作ることになるので、
(3) の後で PR を作ればいいと思います。
実際にマージするのは (8) のタイミングです。

[m-tmatma]

参考情報

窓の杜

https://forest.watch.impress.co.jp/info/sakusya/sakusya1.html

窓の杜では原則として作者様からの登録のお申し出によるソフトライブラリへの収録ではなく、
毎月の収録候補ソフトを窓の杜が選ばせていただき、窓の杜から作者様へ収録許諾を
お願いするというかたちをとらせていただいております。

とあります。

[kobake]

検証作業を容易にするために以下のようにしてはいかがでしょうか?

appveyor で自動的に成果物に対して自動的にsha256 を計算して成果物に含める。

ZIP自体のハッシュを記録する仕組みは欲しいと思っていましたが、
たぶん今のやり方に組み込むとすると、ZIP内容物のファイルそれぞれのハッシュという感じですかね。

GitHub Releases の sha256 と AppVeyor の sha256 が同じかを比較する。

これのハッシュ値同一性のチェックは人間がやるという想定ですか？
（自分のほうでは今のところアイデアは無いですが）その同一性のチェックすらも自動化できる発想があればご提案いただきたいです。

[m-tmatma]

参考情報2

https://ja.osdn.net/projects/sourceforge/news/25778

GitHub アカウントを利用して OSDN アカウントにログインできるようになりました。

[KENCHjp]

@kobake さん

メンテナンスめんどくさいと思うので、GitHub Releases を中継するプロキシCGIをどこかに配置するとか

年に１回か２回かと思うので、手順が明確であれば、CGIを作成/メンテする工数考えると、手動でも十分かなって思ってますが決めの問題かと思います。

あと、現在、バージョンは、４桁になってますが、releaseのtagは３つでもいいかもですね。
「2.a.b.0」→「2.a.b」

前に、話がありましたが、tagに反応して AppVeyorがreleaseの動きをすることはできるとのことで。
https://budougumi0617.github.io/2017/10/13/publish-nupkg-by-appveyor/

[kobake]

https://ja.osdn.net/projects/sourceforge/news/25778
GitHub アカウントを利用して OSDN アカウントにログインできるようになりました。

そうそう、GitHub ログインできるようになったんですよね。
先月の OSDN への移行提案があった時点ではまだこの機能なかったんですけど。ここ最近の機能ですね。
MS による GitHub 買収ニュースへの呼応かもしれませんｗ

[kobake]

年に１回か２回かと思うので、手順が明確であれば、CGIを作成/メンテする工数考えると、手動でも十分かなって思ってますが決めの問題かと思います。

まぁそうですね。個人的には決めすら無くても良いと思ってます。その時点で必要な方がいればコピーを置けば良いし、その時点で必要な方がいなければ無くても良いですし。実はコアメンバーがやる必要すら実はなくて、必要と思った第三者に勝手にやってもらうくらいでも良いと思ってます。

あと、現在、バージョンは、４桁になってますが、releaseのtagは３つでもいいかもですね。
「2.a.b.0」→「2.a.b」

ですね。末尾数字は「人間が決めるところではない」意識でだいたい合ってると思います。
タグ名は「人間が決める範囲の数字」にしましょう。個人的には頭に「v」を付けたいと思ってます。
「v2.a.b」みたいな感じ。

[KENCHjp]

@m-tmatma さん
窓の杜ですが私のソフトも載せてもらってますが、たぶん編集部と調整でのっけてもらえるかとおもっています。
私のソフトより著名だとおもうので＜サクラエディタ
一度のっかるとあとのメンテは編集部側でやってくれるのでこちらは能動的に動く必要なくなります。
たぶん今まではだれにアポとっていいか不明だから話がないだけのような気も(笑)
Vectorは能動的に動けばいくらでも行けますが、窓の杜やVectorはやっぱり第三者的になってしまうので、せっかく外部ならOSDNの方がいいのかなと。

GitHubのアカウントでログインできるということは、AppVeyorとも連携できるのかなぁ。
GitHubで個人じゃなくてチームのアカウント一つ作ってバッチ運用にあててもいいのかもですね。

[KENCHjp]

@kobake さん

個人的には決めすら無くても良いと思ってます。

そう決めた通り動く必要はないのですが、現メンバーがどうやってたかの記録というか手順がないと誰も何もどうしたらいいかわからないので、手順があったほうが後引き継ぐ人が動きやすいかなと。

[KENCHjp]

リリースバイナリは、最低、
・インストーラー
・本体exeのzip
はリリース対象としたいと思います（手動が無く余力があれば、インストーラーと同等のzipと、バイナリだけのzip）

[kobake]

決めすら無くても良い

ちょっと言葉足らずでしたが、ここは「外部コピー」についての言及です。
まぁここも何かしらサブ手順作っておきましょうか。

[kobake]

リリースバイナリは、最低、
・インストーラー
・本体exeのzip
はリリース対象としたいと思います（手動が無く余力があれば、インストーラーと同等のzipと、バイナリだけのzip）

今の AppVeyor の成果物みたいに、実行バイナリもインストーラも全部入ってるZIPでも良いかなーとも思っていますが、どうでしょう。昔とは違って今ならネットワーク環境は皆十分に高速だと思いますし。（そうでもないところが割とあるようでしたら僕の認識不足なので考えを改めます・・・）

[KENCHjp]

ここは「外部コピー」についての言及です。

はい、認識あってます。全然サードパーティーは勝手に転載してもらってもいいかと思うのですけど、いわゆる公式と呼ばれてるところにアップロードするのは、サブ手順はあっていいのかなと。

ちなみに、窓の杜は毎月、来月も乗っけていいか確認のメールが来ます。

[KENCHjp]

今の AppVeyor の成果物みたいに、実行バイナリもインストーラも全部入ってるZIPでも良いかなーとも思っていますが、どうでしょう。

線の太さよりは、ピンポイントでダウンロードしたいニーズはあるかなと。

[m-tmatma]

ちなみに、窓の杜は毎月、来月も乗っけていいか確認のメールが来ます。

へー。

[m-tmatma]

ZIP自体のハッシュを記録する仕組みは欲しいと思っていましたが、
たぶん今のやり方に組み込むとすると、ZIP内容物のファイルそれぞれのハッシュという感じですかね。

とりあえず sha256 の計算結果を成果物の ZIP に含める対応を行いました。

190

[m-tmatma]

線の太さよりは、ピンポイントでダウンロードしたいニーズはあるかなと。

そうですね。実行ファイルだけ使いたい人はいるかもしれないですね。
appveyor で warning 関連のテキストと実行ファイル (言語ファイルも?) と
ハッシュをZIP 圧縮したものを appveyor にあげる対応しましょうか?

[m-tmatma]

（自分のほうでは今のところアイデアは無いですが）その同一性のチェックすらも自動化できる発想があればご提案いただきたいです。

appveyor から GitHub Release にあげられるのであれば
その逆 (GitHub Release から appveyor の実行環境へのコピー)は
できそうに思います。テストはめんどくさそうですが。

ただそんなに頻繁にリリースしないのであれば、
すぐに対応しなくてもいいように思います。

[KENCHjp]

sakura.exe以外のハッシュは、個人的には不要です（sakura.exe単独ダウンロードはしますが、他のモジュールを単独でダウンロードする場面はあまりなさそうなので）。
が取捨選別するほうが手間であればワイルドカード(全部)にhash作ってもいいかもですね。

[kobake]

ただそんなに頻繁にリリースしないのであれば、
すぐに対応しなくてもいいように思います。

ですね、将来余裕があったら（というか気が向いたらくらいで）対応で良いと思います。

[kobake]

sakura.exe以外のハッシュは、個人的には不要です

個人的には .exe, .dll, .msi 等は最低限ハッシュあったほうが良いかなと思ってマス。実行コード埋め込み可能なファイルに変なもの混入しているとマズいので。

[m-tmatma]

前に、話がありましたが、tagに反応して AppVeyorがreleaseの動きをすることはできるとのことで。
https://budougumi0617.github.io/2017/10/13/publish-nupkg-by-appveyor/

tag を push したタイミングで appveyor のビルドが走ることは実際に確認しました。
https://github.com/sakura-editor/sakura/pull/199#issuecomment-401538423

[KENCHjp]

ヒストリーって、コミットログでいいんでしょうか？
直近のコミットログ見ると、フォルダ構造の変更等、内部仕様・構造の変更もおおくて、
エンドユーザ目線の情報ではないなぁと思いつつ。
https://github.com/sakura-editor/sakura/wiki/NextRelease

コミットログから外部仕様にかかわるところだけ抜粋するか、目玉機能だけリリース用Issueで協議して、
詳細はコミットログ見てね的な案内にするか。
段取り的には、 @kobake さんの手順の

(1) 任意のタイミングで master 最新のものをリリース可とみなして良いか皆の決を採る
(2) リリースバージョン番号を考えて決める

この辺り用のIssueで内容決めるって感じでしょうか。
更新対象って、
ヘルプとソースもありっすかね？
https://sakura-editor.github.io/help/HLP_HISTORY.html

https://github.com/sakura-editor/sakura/blob/master/unofficialrelease.txt
https://github.com/sakura-editor/sakura/blob/master/request.txt

[kobake]

コミットログをそのままリリースノートに書くわけじゃないので、そこは人間的なヒストリーになると思ってください。コミットログを一般ユーザに見せるつもりは無いです。見たい人は見てきてくれても良いですが。

ヘルプも対象内で良いかと。

unofficialrelease.txt と request.txt はあと精査したほうが良いかもしれませんが、今は自分は見てないです。

[kobake]

この辺り用のIssueで内容決めるって感じでしょうか。

そですね、リリース間近のあたりでそれ用のIssue作って合意形成進めてくのが良いかと。

[KENCHjp]

unofficialrelease.txt と request.txt はあと精査したほうが良いかもしれませんが、今は自分は見てないです。

そうか、これは、インストーラーに含まれるものじゃないからある意味塩漬けでもいいのかもしれませんね。

この辺り用のIssueで内容決めるって感じでしょうか。

そですね、リリース間近のあたりでそれ用のIssue作って合意形成進めてくのが良いかと。

イメージあいました。

[jakenjarvis]

ひょっこり通りすがりの人ですが、AppVeyorについて答えられそうな事とかを書いてみます。
個人的に調べたばっかりで、記憶が残っているので今のうちに！

運用方法について

• (1) 任意のタイミングで master 最新のものをリリース可とみなして良いか皆の決を採る

これは、pre-releaseブランチでも作ればどうでしょうか。
AppVeyorでDeployするときに、masterブランチとpre-releaseブランチに更新があった場合のみDeployが動作するように設定できます。（ビルドはその他のブランチでも常に動きます。ちなみにビルドもブランチを限定して動かすことが出来ます）

運用イメージは、pre-releaseブランチでTag付きコミットをすると、自動でEXEがビルドされ、どこかにDeployされます。各自でそのEXEの動作確認後、合意が得られたら代表者がmasterブランチへマージしTagを付ける感じです。

GitHub Releasesでpre-releaseとmasterの成果物が混在して紛らわしい、という場合は、ブランチによってDeploy先を切り替えてもよいかもしれません。（ appveyor.yml で provider: の記述を複数記載が可能です）

以下は、成果物「TEST.zip（本体exeのZIP）」と「TEST.exe（インストーラ）」をmasterブランチでTag付きコミットがあった場合はGitHub Releasesへ、pre-releaseブランチでTag付きコミットがあった場合はBintrayへデプロイする最小限の記載例です。
（実際はこれにapi_keyとsecureの記載が必要ですし、これ自体の動作確認はしてません）

artifacts:
  - path: TEST.exe
  - path: TEST.zip

deploy:
  - provider: GitHub
    on:
      branch: master
      appveyor_repo_tag: true       # deploy on tag push only

  - provider: Bintray
    on:
      branch: pre-release
      appveyor_repo_tag: true       # deploy on tag push only

リリースバイナリは、最低、
・インストーラー
・本体exeのzip
はリリース対象としたいと思います

この通り、成果物のartifactは、複数指定可能です！

成果物のチェックサムについて

(7) (6) でアップロードされたバイナリが AppVeyor のものと同一であるかどうか、アップロード者以外の人のほうでも検証 (正式公開内容物のダブルチェック)

これは、少々厄介ですが、やろうと思えば出来ると思います。（やったことないけど）
既にZIP内にsha256のテキストが入っている前提だと、以下のような流れでしょうか。

• appveyor.yml の after_deploy: で、デプロイ後の処理として以下を動かします。
• GitHub Releasesのページからスクレイピングして、デプロイされたZIPファイルをダウンロード（ How to download file ）します。
• アクセスするアドレスは、 https://github.com/sakura-editor/sakura/releases/latest にアクセスします。
• AppVeyorからのスクレイピングは、seleniumを使えばできます。（ Selenium testing ）このページのやり方じゃなくてもPythonとかRubyが動かせるのでSeleniumを pip install selenium や gem install selenium-webdriver な感じでインストールして普通に実行してもいけそうな気がします。

ちょっと心配なのは、デプロイでGitHub ReleasesにUPした直後に、ZIPファイルをダウンロードできるかどうか・・・でしょうか。

・・・が、そもそもこれって必要でしょうか？（AppVeyorの手元に成果物もあるし・・・）

個人的には、 公式配布サイトにsha256のコードを晒すべきだ と思います。sha256の公開元が保証されなければ、ユーザとしてはチェックする意味がありません。
「改竄したEXE」と「改竄後EXEを元に算出したsha256」が同梱されたZIPファイルを配布されたら、意味がないからです。
なので、sha256公開ページを作っておき、 after_deploy: のタイミングでAppVeyorからリポジトリに自動更新＆コミットさせるほうが現実的だと思います。（ Pushing to remote Git repository from a build ）
※これ以外にも、Github Pagesを使うなど、やり方はいくつかあると思います。

AppVeyorからgithubへのデプロイやコミットについて

github側で、 Personal access tokens のページで、public_repoの権限を与えてトークンを発行し、AppVeyor側に登録することと、このトークンを Account → Encrypt data tool で暗号化し、それをapi_keyのsecureで指定してあげなければなりません。
また、コミットまでする場合は、もっといろいろ指定してあげなければなりません。（やったことないので説明は避けますが、上記リンク先に英語で記載があります）

また、githubの左上の検索ボックスで、「appveyor.yml git config global」あたりをキーワードに検索すると、実際にコミットまでさせてるymlが引っかかるので、いろいろ参考になりますよ。

長文失礼しました（汗）

[KENCHjp]

@jakenjarvis さん、通りすがりありがとうございます。
まだリリースゼロなのでいろいろと有識者のご意見聞きたいところです。
いただいた情報このIssueで肉付けしたいとおもいます。
げんざい、リリース周りに力を避ける人が少ないので、もしよろしければ今後とも相談ににっていただければ幸いです。

[KENCHjp]

あとtagの実験の話は　#121 にもございます。

[jakenjarvis]

あう。121で詳しく話が出てますね（汗）ここを先に見るべきでした。
有識者というほど、私も明るいわけではないのですが、何かお手伝いできることがあればと思います。

で・・・せっかくなので、手元で変更して試しているところなのですが、一つ不具合の原因を発見したので、別のissueで報告しますね。

[KENCHjp]

別のissueで報告しますね。

ありがとうございます。助かります。

[KENCHjp]

いったんWiki側へリリース手順展開されたので本Issue閉じます。