nashcft's blog

時々何か書く。

bitrise.io における workflow の差分管理

昨年末に Bitrise Advent Calendar 2019 を眺めてたら、以下の記事で bitrise.io 上で bitrise.yml の差分管理ができるって書いてあって、気になって調べてみた話。

qiita.com

記事には差分管理の機構について紹介がなかったので、"bitrise yml diff" とか "bitrise yml version control" とかそんな感じで検索してみたら、Bitrise 公式ページの Features > Workflow editor に以下の記述があり、どうやらビルド単位で workflow のスナップショットをもっているっぽいことがわかった。

Bitrise saves each build’s configuration state and if changed you can check out a diff between the older and the new versions. Something seems off? Click restore to roll back to an earlier version.

www.bitrise.io

それからもう少し調べてみたところ、bitrise.io 上での bitrise.yml の管理について書かれたドキュメントに行き着いたので完全理解した。Bitrise はコアの部分のドキュメントはちゃんとしているので公式ドキュメントにたどり着いたら実質ゴールである。この調子で各 step でできることのドキュメントも充実させてほしい。Step の振る舞いを理解するのに毎回レポジトリを探してコードを読むのは何か間違っている気がするので。

devcenter.bitrise.io

ドキュメントによると、できることは以下の3つとのこと:

  • 各ビルドの実行で使われた bitrise.yml のスナップショットの確認
  • 「現在の」 bitrise.yml との差分の表示
  • そのスナップショットへのロールバック

あくまで「変更履歴の管理」じゃなくて「現在との差分管理」なんだなあと思わずにはいられないが、CIの workflow にそんなリッチな変更管理はいらないのかもしれない。でもたくさんのビルドが間断なく実行されるような開発環境で変更前のビルドを掘り出すみたいなケースを想像すると、やっぱり「いつ・どんな」変更をしたかをビルドとは独立して記録しておいた方が便利じゃないかなあって思った。

最初は調べてみて良い感じだったらレポジトリ管理から乗り換えようかと考えていたけど、自分の求めているような機能ではなかったのと、レポジトリで bitrise.yml を管理する理由って、開発の並列度の関係で新しい workflow の実験中は変更の適用範囲を限定したいとか、レポジトリの状態 (ツールのバージョンとか build script の変更とか) と常に同期させたいとかも含まれてて、変更管理だけではないなあということに気がついたので、結局これからもレポジトリで bitrise.yml を管理し続けるだろうという結論になった。おわり。