お久しぶりです！パイオニアの SaaS Technology Center(STC) モバイル開発部の新卒3年目の菅野です。

今回は、モバイル開発部 開発チームで掲げているアプリ開発の内製化戦略として取り組んでいる「自動化環境の構築」について紹介しようと思います！

※本記事は以前投稿した「パイオニアの「アプリ開発内製化」への道（その１） シフトレフト戦略×自動化基盤構築」の続きとなっているため、まず先にこちらの記事をお読みいただければと思います。

はじめに

前回の記事では、開発チームでの課題の解決や、開発の内製化、アジャイル開発への移行に向けた戦略を紹介し、自動化環境の基盤づくりとして、ソースコードのバージョン管理をSVNからGitHubへの移行した話を紹介しました。

本記事では、CI/CDツールであるBitrise(ビットライズ)を導入してビルドや、配信作業の自動化環境を構築した話を紹介します。

そもそもCI/CDツールって？

*CI/CDという、
「ソフトウェアの変更を常にテストして、自動で本番環境にリリース可能な状態にしておく」
というソフトウェア開発の手法を実現するためのツールです。

CI/CDは、単に作業効率を上げるだけでなく、テストやビルド作業から属人性を無くせるのがメリットです。

つまり、テスト担当者ごとによる品質のばらつきや人的ミスを排除できるのです。

また、CI/CDによって、
「機能を追加したらテスト・ビルド・デプロイを実行し、すぐに動作確認」ということを自動で繰り返すことで、品質を確保しつつリリースを高速化することができるようになります。

Bitriseの導入

私のチームではモバイルアプリ開発におけるCI/CDツールとして「Bitrise」を採用し、自動化を実現しました。

実現にあたって、Bitriseを採用した理由や自動化環境の構築の際につまづいたところだったりを紹介します。

なぜBitriseにしたのか

私たちのチームがCI/CDツールとしてBitriseを採用したのは、
・モバイルアプリに特化している(Android、iOSネイティブ、Flutterに対応している)
・GUIで操作できるためわかりやすい
・クラウド型サービスのため、メンテナンスが楽
という理由からです。

Bitriseはモバイルアプリに特化していて、なんと言ってもUIが見やすく、ワークフローと呼ばれる可視化されたフロー図で、ビルドプロセスがとても分かりやすいです。

また、クラウド型サービスであるため、誰でもアクセスしやすく、クラウド上に構築された仮想環境で動作するため、ローカルPCのメンテナンスといった骨の折れる作業も不要です。

環境を構築した人でなくても簡単に理解できて、操作できるため、メンテナンス作業を別のリソースに割り当てることも可能です。

CI/CDツールの有名どころで言うとCircleCIやFlutterであればCodemagicなどが挙げられますが、上に記載した理由や、開発チームにBitriseのナレッジが少々あったということもありBitriseを採用しました。

つまづきポイント

AndroidもiOSも初期設定の手順はとても簡単で、デフォルトのワークフロー(primary)が初めに作られるため、画面に表示されたとおりに進めていけば、GitHubリポジトリとの連携やビルドの設定を完了できます。

ただ、初回のビルドはまぁまぁの確率で失敗するのではないかと思います。

アプリにもよるとは思いますが、私が関わっているプロジェクトのアプリでは、以下の問題でハマりました。

・証明書周りでエラー
・Testが失敗している
・ビルドのConfigurationが指定されていない or 設定値が不正
・ブランチモデルを新たに導入したため、ワークフローとそのトリガーの整理と理解に時間がかかった

証明書に関してはストアにリリースするタイミング以外ではそこまで深く意識しなくて済むのですが、今回Bitriseで動かすときに少しハマってしまいました。

原因としては通常のビルド設定にRelease署名の設定が組み込まれておらず、証明書が違いますよといったエラーや、設定されていませんよといったエラーが出ることでした。

ただ、Bitrise 上でエラーログを確認することができるため、どこで失敗しているのかがとても分かりやすかったです。（エラーを解消するためにはGradleの知識や、Xcodeのビルド回りの知識が少し必要でした。）

ただ、ネット上にもBitriseに関する記事が多くあったため、それらを参考にしたり、社内の有識者にアドバイスをもらいながら環境の構築が出来ました。

また、Bitriseのハマりポイントというわけではないですが、Bitriseでは複数のワークフローを設定できるので、(新たに導入したブランチモデルの理解と合わせて)どのブランチへのPushをトリガーにしてどのワークフローを走らせるかの運用の整理と理解に1番時間がかかってしまった気がします。

整理した運用はこちらになります。

BitriseではStepと呼ばれる処理のパッケージを組み合わせることでワークフローを作成することができ、様々なStepが用意されているため、大体のことは実現できます。

例えば、Bitriseでのビルド結果をSlackやTeamsに通知を行うStepやスクリプトを組んで実行できるStep、UnitTestを実行できるStepなどがあります。

通知はとてもありがたいですね。
Slackでは、Slack上からBitriseのワークフローを走らせたりなんてことも出来ちゃうんですよね！

検証版の配信

今まで手動の作業で工数がかかり、課題となっていた「社内への検証版配信」もBitriseを導入したことで自動化を実現しました。

Bitriseには、ビルドや署名といったStepの他にDeployGateなどへデプロイするためのStepなども用意されているため、ワークフローにStepを追加すれば各種サービスと簡単に連携が行えました。

従来は、APKファイルをそのまま展開したり、GooglePlayの内部テストやTestFlightに手動でアップロードして配信するという形式で行っていましたが、
「GitHubへのPushをトリガーにしてビルドが走り、完了したらDeployGateで配信する」
というワークフローを作成したため、手動オペレーションを無くすことができました。

今後について

今後としては以下の図のようにモバイルE2Eテスト環境の構築や、TestRailの導入を行い、アプリの品質の向上に向けて取り組んでいく予定です。

構築が完了した際にはnoteに記事を投稿予定ですので、お楽しみにして頂ければと思います！

実際にやってみて

前回の記事から約1か月経ってしまいましたが、Bitriseを導入し「ビルド→検証版配信」の工程を自動化することができました。

構築してみての感想としては、

Bitriseって素晴らしいっ！！！！

この一言に尽きます。

長くなってしまいましたが、最後までお読みいただきありがとうございました！

おわりに

パイオニアでは、変革に向けて一緒に働く仲間を募集中です！ 老舗メーカーの変革に少しでも共感、チャレンジしてみたいと思われた方は、採用ページ をご覧ください。

また、カジュアル面談も歓迎しています。
パイオニアのアプリ開発に興味を持たれた皆さま、気兼ねなくご応募ください！