本記事は、Bitrise Advent Calendar 12日目の記事です
私が所属するチームではiOS、AndroidアプリともにBitriseを使っており、普段から大変お世話になっております！
今回はYAMLファイルについて書いてみようと思います。

bitrise.yml に助けられた話

ある日の私は焦っていました。
「このワークフローが走る開発環境を変更したいけど、一体どこで設定しているんだ…？」

先人が作ってくれたワークフローだったため詳しい設定まで把握できておらず、
GUIで各ステップの中を確認するも、環境設定している箇所を見つけられずにいました。

そんなとき仲間の一人がこう言いました。
「bitrise.yml ファイル内を検索してみたらいいよ」と。

bitrise.yml...?

見つかりました。

無事、狙った開発環境にてベータ配信することができました。
bitrise.yml よ、ありがとう…！！

bitrise.yml って何？

そもそもYAMLとは

構造化されたデータを表現するためのフォーマット
- 実際は各種フレームワークやツールで設定ファイルを書くとき、データの保存をするときなどによく使われる
- あくまでも仕様を表すため、仕様を処理する実装が別途必要
- Ruby on Railsの設定ファイルなんかもYAMLで書かれている
YAML Ain’t Markup Languageの略
拡張子は.yml

bitrise.yml ファイルとは

YAMLで書かれたBitriseの設定ファイル
ワークフロー作成時に自動生成される
そのAppに対して設定しているすべてのワークフローが記載されている
YAMLファイルを直接編集して保存すると、ワークフローにも反映される

↓内容の一例

bitrise.yml

workflows:
  primary: #primaryという名前のワークフロー
    steps:
    - git-clone: {}
    - cache-pull: {}
    - install-missing-android-tools:
        inputs:
        - gradlew_path: "$PROJECT_LOCATION/gradlew"
    - android-lint:
        inputs:
        - project_location: "$PROJECT_LOCATION"
        - module: "$MODULE"
        - variant: "$TEST_VARIANT"
    - android-unit-test:
        inputs:
        - project_location: "$PROJECT_LOCATION"
        - module: "$MODULE"
        - arguments: "--stacktrace"
        - variant: "$TEST_VARIANT"
    - gradle-runner:
        inputs:
        - gradle_file: "$PROJECT_LOCATION/build.gradle"
        - gradlew_path: "$PROJECT_LOCATION/gradlew"
        - gradle_task: ktlintCheck
        title: Gradle Runner / ktlintCheck
  beta: #betaという名前のワークフロー
    steps:
    - git-clone: {}
    - cache-pull: {}
    - install-missing-android-tools:
        inputs:
        - gradlew_path: "$PROJECT_LOCATION/gradlew"
    - android-lint:
        inputs:
        - project_location: "$PROJECT_LOCATION"
        - module: "$MODULE"
        - variant: "$TEST_VARIANT"
    - android-unit-test:
        inputs:
        - project_location: "$PROJECT_LOCATION"
        - module: "$MODULE"
        - arguments: "--stacktrace"
        - variant: "$TEST_VARIANT"
    - gradle-runner:
        inputs:
        - gradle_file: "$PROJECT_LOCATION/build.gradle"
        - gradlew_path: "$PROJECT_LOCATION/gradlew"
        - gradle_task: ktlintCheck
        title: Gradle Runner / ktlintCheck

bitrise.yml の管理方法

大きく分けて2パターンありそう。

GUIで管理する
リポジトリに bitrise.yml を入れて管理する

私のチームでは普段GUIで管理しており、今のところ特に不便に感じることはありません。
会社によってはリポジトリに入れて管理をしているところもあるようですが、Bitriseにはワークフローの差分管理機能があるので、差分管理するためだけにリポジトリに入れる必要はなさそうとのこと。
このあたりはpixivさんの下記記事が大変参考になりました。

モバイルアプリのCIをBitriseにして1年が経ちました - pixiv inside

プロダクトによってワークフローやトリガーの設定の仕方は様々で、リポジトリに bitrise.yml を入れてワークフローの差分管理をしているプロダクトもあります。しかし、多くのプロダクトではGUIでワークフローを管理していて、個人的にもGUIでワークフローを管理するのはアリだと思っています。他プロダクトのワークフローがどうなっているか視覚的に参考にしやすいので、自然に各プロダクトのワークフローが良くなっていく実感があります。 Bitriseには過去のワークフローに戻せる差分管理機能が実装されているので、差分管理するためだけに bitrise.yml をリポジトリに入れる必要はないと思います。

おわりに

ワークフローの設定を一括して変えたいときや、お目当ての項目が見つからないときなどに、 bitrise.yml を活用できるといいのかなと思いました。
これからもBitrise使っていきます！

BitriseのYAMLファイルについてまとめてみる