Sakura: インストーラーパッケージ作成運用たたき台

[KENCHjp]

とりあえずたたき台を作成。思いつくまま書いてしまったので多々突っ込みよろしくお願いします。

■インストーラーパッケージ作成運用手順（理想）
　１）コミッターのリクエストを受けリリース用Issue作成
　２）バージョン番号の決定
　３）ダイナミックコンテンツ選定（exe,dll,ヘルプ）
　４）スタティックコンテンツの追加、変更選定（キーワードファイル他）、リリースノート更新。
　５）リリースパッケージ用ブランチ作成しPR
　　→ブランチは作成せず、masterに直接コミット？
　６）問題なければメインへコミットしインストーラー生成（Appveyor自動）
　　→タグ付を契機にAppveyorにてインストーラー生成。
　７）インストーラー動作確認（ローカルにインストール・アンインストール素振り実施？）
　８）必要・可能ならリリースモジュールのダウンリードサイトへの自動反映（？必要）
　９）関連ドキュメントWebサイト等の自動修正

■インストーラーパッケージ作成運用手順（暫定手動）
　理想形の１）～５）まで同じ、６）のインストーラー作成をローカルで実施してコミット
　８）、９）を手動で実施。

■現状課題メモ

• [x] 　１）Inatallerの一部ファイルがリポジトリ上zipで圧縮されている。
  　　zipを展開する。 #41
  　　各バイナリ（exe,dll,ヘルプ)もチェックインする？
  　　このプロジェクトで生成するバイナリはチェックインせず、インストーラ作成時にダイナミックに取り込む？
  　　外部DLLファイルはチェックインしておく。 #81
• [x] 　２）カラーファイル他もkeywordフォルダに入ってる。
  　　　フォルダ名を適切なものにしたほうがいいか？
  　　　フォルダ名を変えた場合上書きインストールでファイル重複してしまう。
• [x] 　３）DLL,ライセンスファイル、ヘルプが一ファイルずつ定義されている
  　　フォルダにいれてワイルドカードで取り込むと今後増えたときにメンテが楽、漏れがなくなる。
  　　DLLの場合フォルダが変わる場合にプログラムで呼び出せなくなる？
• [x] 　４）64bit用インストーラー作成
  　　・installとは別リポジトリにするか、同じリポジトリで管理するか。
  　　　リポジトリを分けた場合、双方同じリソースを二重メンテにならない工夫が必要。
  　　　一つのリポジトリで管理する場合、同じファイル名で32bitと64bitで変わるDLL等がある場合別のフォルダに入れるなど一考要。#81
  　　　例）リポジトリ上は
  　　　　installer
  　　　　　resource32
  　　　　　　.dll
  　　　　　　*.txt
  　　　　　resource64
  　　　　　　.dll
  　　　　　　*.txt
  　　　　としておき、インストール時にファイルをインストール先直下に展開されるようにする。
  　　　ファイル名にかぶりが無いのであれば本件不要クローズ。
• [x] 　５）ファイル追加
  　　　licenseファイル #66
  　　　他keyword
• [x] 　６）Windows10メニュー対応 #104
• [x] 　７）インストーラーの他にzip圧縮されたファイル（exe単体、バイナリ全部、キーワードファイルも含めた全部)も自動生成する
• [x] 　８）exeファイルよりバージョン番号を取得してインストーラー他のバージョン番号が記載されているところを一括修正する仕組みを検討

Pascal使えると言った手前、課題の６）から手を付けようかなと。
リポジトリいじるのはフォルダ構成の方向性固まったら実施かなと思います。
64Bit版リリースの時に（暫定手動）運用発動するのがひとまず目標ですかね。

[m-tmatma]

バージョン番号がソースとか インストーラ用の設定ファイルとか
分散しているので一括で更新できるスクリプト等の仕組みが欲しいですね

[KENCHjp]

@m-tmatma さん、私の拙作ソフトでは、VBS(GetFileVersion)でexeからバージョン番号取得してインストーラーの定義ファイル更新と圧縮するzipファイルのファイル名を修正してました。
手動ならvbs叩くだけなのですが、Appveyorで動くものやら。
これもタスクにいれときますかね。
一応、インストーラーほかのファイル名は、exeから取得できるバージョン番号にする方向であればですが。

[KENCHjp]

Appveyorで動くものやら。

そうか一度ローカルに持ってくるからそこで一発動かせばいいのかな。

[berryzplus]

たたき台作成お疲れ様です。

なんとなく、リリース専用のブランチがあったらいいなと思っています。

• appveyorのビルド設定はたくさん作れる
• appveyorの設定はブランチを指定できる
• appveyorの設定は設定ごとにappveyor.ymlの名前を指定できる
  　→　リリース用に appveyor_release.yml を用意して、git clone～ビルド～パッケージをさせる

こうしておけばリリースブランチに Push すると勝手にパッケージされますよね。
ビルド工程をまとめた yml を記述してあげれば、パスやらバージョンやらの扱いもしやすいはず。

一筋縄ではいかないような気もしますけど、できたらいいな (^-^;

[kobake]

うーん、リリースはタグ管理が良いんじゃないですかね。hotfix出す必要があるときだけブランチ切るくらいで良いかなと思ってます。

[berryzplus]

release_2_3_3じゃなくて、releaseを切る感じで考えてました。
リリース番号のタグ管理には賛成です。
単にリリースイベントのトリガをとるためだけにブランチを分ける案を出してます。
もし他の方法で appveyor ビルドのトリガを行えるならブランチは作らなくてよいです。
（マニュアルちゃんと読めてないですが、他の方法のトリガもありそうです。）

ポイントは、トリガ発動したら git clone～ビルド～パッケージ作成が一連動作として走るようにできたらいいね、です。できるかどうかは、現段階で不明 :cry:

[KENCHjp]

@kobake さん

リリースはタグ管理が良いんじゃないですかね。

ブランチ切らないということは、PRしないということ？
@berryzplus さんの書いた、Pushすると勝手にパッケージ作成を狙いたいなぁと思っているのですが、
その"手段"の技術的なところがまだよくわかっておりません。

手順としては、含めるものが決まった前提で、

１．リポジトリをチェックアウト、
２．含めるリソースを全部上書き＋追加
３．ブランチ(release)へPush→appveyorがインストーラーパッケージ作成
４．動作確認して問題なければ、メインへマージ、ブランチは削除

appveyorの自動化が難しい場合、３．ではローカルで、インストーラーを生成して、どっかへアップロードって感じかなと。

[kobake]

基本的に PR は作りますが、あくまでも master へのマージ用 PR を想定しています。

master へのマージを確認した後、その最新状態の master をパッケージ化したい場合には git-tag 機能 によりタグを打って push という流れが良いかな、と。
タグ追加を自動検出してそれを元にパッケージ化ジョブを走らせることもできたはずです。自分ではやったことないんですけど。

現在リリース済みのパッケージ（これは手動アップロードです）はタグに紐づける形にしています。
https://github.com/sakura-editor/sakura/releases

Git のタグって Svn のタグとは違って枝分かれさせるものではなく、特定コミットにラベルを付けるような概念なんです。枝分かれが無い分、管理が楽です。

タグはこのあたり↓から見れます。

[k-takata]

タグをpushしたときにAppVeyorを走らせることも可能です。なので、タグの場合だけパッケージを作るということも可能です。
https://github.com/vim/vim-win32-installer はそのようにしています。

[k-takata]

vim-win32-installer では、インストーラ作成用のリポジトリは vim 本体とは別にしてあり、本体は git の submodule で取り込んであります。メンバーの個人サーバー上で cron で1日1回 vim 本体のリポジトリの更新を監視して、更新があればインストーラも更新を行っています。
あるいは、AppVeyor に申請すれば自前でサーバーを用意しなくとも定期的にビルドを実行させることも可能です。

[KENCHjp]

@kobake さん、 @k-takata さん
リリース物をどこに置くんだろうと思ってましたら、
https://github.com/sakura-editor/sakura/releases
ここなんすね！
あと、tagを打ってマージってのも知らなかったので勉強になります。
で、PRってブランチ無くてもいけるんですね。
もうちょっと勉強します。

ただ全自動でビルドはないかなと思っております。
１日の終わりにどういう状態にしておかなければならないか相当統制のとれたDevチームじゃないと難しいのかなと。
それよりは、バージョン番号どうしよう、カラーファイルこれいれようかとか考えて、必要なものをpushしておき、おりゃってインストーラ作成するのかなと。

[kobake]

正式リリースのパッケージ内容・タイミングは人間の判断で良いと思います！（というかそれしか無い）

いろんなプロジェクトで目にする Nightly Build みたいなやつは、実行ファイル単体に限ってはもう既に組み込まれているという認識です。 https://ci.appveyor.com/project/sakuraeditor/sakura/branch/master これがそれにあたります。Nightly というよりは Latest ですね（むしろ Nightly よりもさらに迅速）。

あと、tagを打ってマージってのも知らなかったので勉強になります。
で、PRってブランチ無くてもいけるんですね。

tag の場合は PR 作る感じではないです。
既存の状態にラベルを付けるだけですね。
つまり、tag って「ファイル変更はしない（できない）」んです。

このあたりはホワイトボードとかで説明できればパパパっとすぐ説明できるんですが、テキストベースで伝えるの難しいｗ

まだ次リリースまで時間ありますし、このあたりはゆっくり習得していきましょう。
Git っていろいろ覚えること多いんですよね～

[KENCHjp]

＞まだ次リリースまで時間ありますし、このあたりはゆっくり習得していきましょう。

ですね。とりあえず目先の技術的課題と、iss他のバージョン情報を一括メンテするvbsでもこしらえます。

[k-takata]

ちなみに今、とあるプロジェクトで考えているリリース方法はこんな感じです。

• タグがプッシュされたら、自動でパッケージをGitHub releasesにアップロードされるように設定しておく。ただし、pre-release状態で公開されるように設定しておく。
• 必要なPRをmasterにマージし終わって、リリースの準備ができたら、タグを付けてプッシュ。
• GitHub releasesに上がったパッケージを確認し、問題がなければ、GitHub releasesにリリースノートを書き、pre-releaseをreleaseに変更して完了。

[kobake]

pre-release 方式良いですね！
サクラエディタもできることならそういう形で運用できると理想です。

[berryzplus]

appveyorのトリガはまだちょっと気が早かったかな・・・。

やれそうな雰囲気がバシバシあるのは、すごくいい感じ :smile:

[kobake]

できるところからゆっくりやっていきましょう。
既存実績があるのはとても心強いです❗️

[m-tmatma]

124 で技術的にインストーラを appveyor でビルドできるところまで確認しました。

[m-tmatma]

124 で技術的にインストーラを appveyor でビルドできるところまで確認しました。

英語用のリソースはまだ入れてませんが、簡単に追加可能だと思います。

[m-tmatma]

英語用のリソースはまだ入れてませんが、簡単に追加可能だと思います。

a84fac8b1ea52a878e3261bf1e0faf16254dbdeb で確認しました。

[m-tmatma]

installとは別リポジトリにするか、同じリポジトリで管理するか。

iss ファイルだけを分けたらいけそうです。

[m-tmatma]

exeファイルよりバージョン番号を取得してインストーラー他のバージョン番号が記載されているところを一括修正する仕組みを検討

exe より取得するよりは、スクリプト等で複数箇所に存在するバージョンを一括で
更新したらいいと思います。

こんな感じでスクリプトを実行したら必要な箇所をすべて書き換えるというやり方です。

update_version.py 2.4.0.0

必要に応じてバージョン番号の各桁を別のコマンド引数で渡してもいいです。
↓ こんな感じ

update_version.py 2 4 0 0

こうすれば例えば CI の中で、インストーラや EXE の末尾のバージョンに build 番号を
いれるみたいな運用も技術的には可能です。

[KENCHjp]

@m-tmatma お疲れ様です。仕事早い。
一応、サンプル置いてみました。 #128 (初PR、GitHubと格闘している時間の方がまだ長いwww)
「update_version.py 2 4 0 0」この案でも全然問題ないと思いますが、自動取得だとOpsチームの手数が一つ減るかなって思っただけです。オペミスが割り込む余地は減らしたい以外の意図はまったくありません。

[KENCHjp]

67 にも書きましたが、innosetup-5.6.1-unicode.exe だと、issがエラーはいちゃたのでappveyor がバージョンアップしたらなにがしか対応が必要になるかも。

[KENCHjp]

Python ってappveyor でも動くのかしら、もし動くのなら、Version情報が決まったらそれ用のファイルにリリースVersion記載するか、exeから自動取得するか別にして「update_version.py」らしきものを動かせば、ローカルPC作業じゃなくてもいけるっすね。

[m-tmatma]

「update_version.py 2 4 0 0」この案でも全然問題ないと思いますが、自動取得だとOpsチームの手数が一つ減るかなって思っただけです。オペミスが割り込む余地は減らしたい以外の意図はまったくありません。

EXE の中のバージョン番号自体複数箇所に存在していると思うので
それとインストーラのバージョンもまとめて更新してしまえば
バージョンの更新は一回で済むという意図です。

バージョン番号の更新自体はどうせ手動でしないといけないので
そのときにやってしまえます。

[KENCHjp]

なるほど、Devチーム責任でバージョン番号が影響するリソースを全部書き換え要って作戦ですね。
ならば、Opsチームは単にインストーラ作成を発動すればいいだけですね。

[m-tmatma]

Python ってappveyor でも動くのかしら、

はい。過去に別件で使ったことがあります。

また好きなバージョンを選べます。
https://www.appveyor.com/docs/build-environment/#python

別に python でなくとも速く簡単に書ける言語であれば
他の言語、例えば C# でもいいと思います。

[m-tmatma]

あとは、６）かぁ、やるかぁ(笑)

124 で使ったブランチから分岐すればすぐに試せます。

[KENCHjp]

あれ、なんか書いたのが消えてるような・・・

あとは、６）かぁ、やるかぁ(笑)

これ書いたのが消えてる？？？

[KENCHjp]

C#はコンパイル必要なのであんまりやりたくないですねぇ。
Pythonは超苦手ｗｗｗ(まだ、node.jsの方が触れるT_T)
PowerShellはテキスト操作で文字コードでどはまりしたので、テキスト操作は、もっぱらJScriptかVBScriptだったりする軟弱もの。。。

[m-tmatma]

C#はコンパイル必要なのであんまりやりたくないですねぇ。

そうですね。

Pythonは超苦手ｗｗｗ(まだ、node.jsの方が触れるT_T)

最近急激に流行りだしているみたいですよ。
機械学習とかの影響かな。

私も最初心理的にハードルがありましたが、
なれたら便利ですよ。

[KENCHjp]

とりあえず、innosetup-5.5.9のGetWindowsVersionExをWin10で動かすとちゃんとメジャーバージョンに10って返ってくる＼(^_^)／
古いInnoでインストーラー作ると、6って返ってくるので、おそらくmanifest組み込まれてるんじゃなかろうかと。
以下参考。
http://yamatyuu.net/computer/program/sdk/base/GetVersionEx/index.html

Windows10かどうか判断するfunction作ってIconsでCheck判定してショートカットをOn/Offするところまでは出来たのですが、スタートメニュー直下に作る指定ではまり中。。。
このままfunction以外ノンコーディングでいきたい。
まだ、Windows10(64Bit)とWindows7(32Bit)でしか動かしてないですが。
以上中間報告。

[KENCHjp]

それと、issはバージョン情報書き換え対象にしなくてもよさそうです。

define MyAppVer GetFileVersion("sakura.exe")

でバージョン情報が取得できます。
で試してませんが、

define MyAppVerH StringChange(MyAppVer, ".", "-")

とやると2.3.0.0を2-3-0-0に置き換えられそうです。
以下参考。
https://hibara.org/blog/2012/09/04/how-to-innosetup/

[KENCHjp]

とりあえず、ショートカットは相対指定でできるの確認したので、これで一応一通り技術的なところはクリアできたような。
後は、PRかぁ、前のPRも役に立たないので取り消さないと、、、
GitHubと格闘する時間の方が相変わらず長いT_T

[KENCHjp]

あ、あかん。
https://github.com/sakura-editor/sakura/releases
ここに自動でコンパイル結果反映できるんでしたっけ？

[m-tmatma]

あ、あかん。
https://github.com/sakura-editor/sakura/releases
ここに自動でコンパイル結果反映できるんでしたっけ？

https://github.com/forexample/github-binary-release
にやり方の例があります。

できそうですよ。

[KENCHjp]

@m-tmatma さん、了解です、ありがとうございます。
これで一通りネタはそろったかな。

[m-tmatma]

Sandbox のリポジトリとかで練習してみたらいいと思います

[KENCHjp]

とりあえず、個々の課題のおさらい。

１）Inatallerの一部ファイルがリポジトリ上zipで圧縮されている。 #41
　→ひとまずzipファイルとlicenseファイル等は取り込む。
　　各バイナリはその時に、指定されたモジュールを取得してコミットする。
　　外部DLLファイルはコミットしておく。 #81
２）カラーファイル他もkeywordフォルダに入ってる。
　→こちらはひとまずインパクトが大きいのでそのままにしたい。
３）DLL,ライセンスファイル、ヘルプが一ファイルずつ定義されている
　→こちらもひとまずそのままがいいかなと追っています。
　　同一フォルダにビット違いのものを入れておいて各々issで切り替えたりできるかと。
４）64bit用インストーラー作成
　→こちらは、issを分けて出来そう。
５）ファイル追加
　→１）とほぼ同件 #66
６）Windows10メニュー対応 #104
　→できました。　#130
７）インストーラーの他にzip圧縮されたファイル（exe単体、バイナリ全部、キーワードファイルも含めた全部)も自動生成する
　→こちらもやり方は確認できたかなと。 #124 こちらでバッチファイル内で成果物まとめると行けそうですよね。
８）exeファイルよりバージョン番号を取得してインストーラー他のバージョン番号が記載されているところを一括修正する仕組みを検討
　→ことインストーラーに関してはInno Setupの機能で実現可能なことを確認できたので、いったんクローズ。 #130

[KENCHjp]

インストーラーパッケージはAppveyorで自動作成されることが確認できたので、
一旦本Issueはクローズして、作成されたインストーラーをどうやって、
releaseするかで別Issueを作成したいと思います。