こんにちは。コーポレートスタッフの茂木です。
今回は、フィノバレーの提供するデジタル地域通貨プラットフォーム『MoneyEasy』のAndroidアプリ開発を担当している島本さんに、昨年にイチから構築した CI/CD環境の概要とその経緯 について、語っていただきました。
こんにちは、株式会社フィノバレーでAndroidエンジニア（兼 自称：駆け出しUXリサーチャー）をやっております、島本です。
CI/CDの構成をご紹介する前に、MoneyEasyのAndroid開発の基本的な環境について簡単に紹介します。
● コード管理：GitLab
● ブランチ戦略：
○ master（リリース用）
○ develop（開発用）
○ feature（Issueに紐ついている作業用、developにマージしたら消す）
● APK配布：DeployGate
これは、Androidアプリ開発現場ではよく見られる構成だと思います。ひとつ特殊なのが、MoneyEasyは プラットフォーム だということです。
弊社では、MoneyEasyを使った地域通貨として既に「さるぼぼコイン」「アクアコイン」を運用しています。Androidアプリは、それぞれの環境ごとにリポジトリを分けてはいません。つまり、先程述べた両アプリは同じコードで動いています。
アプリ名やテーマカラーをはじめとして、様々な仕様上の違いがありますが、これは productFlavors を分けることで解決しています。
環境は、大きく分けて社内開発用（ DEV環境 ）、アプリごとのステージング環境（ STG環境 ）、アプリごとの商用環境（ PRD環境 ）があります。
機能の新規開発やバグの修正などはDEV環境で行い、ここで実機テストを行っています。
それぞれのアプリごとの機能・デザインのテスト、およびクライアントでの確認はSTG環境で行います。ここでのクライアントとは、さるぼぼコイン：飛騨信用組合様、アクアコイン：君津信用組合様を指しています。
最後に、リリースされているアプリが動いているのがPRD環境です。
まず、以下が現在動いているCI/CD構成の全体図になります。
各ステップについて簡単に説明します。
ローカル環境では、 git hook を使って自動で以下の処理を行っています。
● commit: 開発者のローカル環境で git commit する際、 ./gradlew ktlintFormat を実行
● push: ブランチを git push する際、 ./gradlew app:lint{DEV環境用のビルドバリアント名} を実行
そして、GitLabでは以下のタイミングでUnit Test、UI Test、APKのビルドを行っています。
● feature branch push: pushされたfeatureブランチでUnit Testを実行
● feature -> develop merge: developにfeatureブランチがマージされた際、Unit TestとUI Testを実行
● add tag: ルールに沿った名前のタグがつけられた際、そのタグ名に応じたビルドバリアントでAPKを作成
全容についてはざっと掴んでいただけたでしょうか？
この構成に至るまでには、第1弾・第2弾と段階を踏んでいます。
次は、それぞれのステップについての詳細と経緯について、時系列で説明していきますね。
ちなみに、この構築にあたっては、2018年に出版された『 PEAKS（ピークス）｜Androidテスト全書』 を全面的に参考にしています。この本がなければ構築できなかったと言っても過言ではありません。まさにバイブルです。関係者の方々、本当にありがとうございました。
いきなり現在の姿とは違う目標が掲げられていますね。理由については後ほどお話します。
まず最初にCI/CD構築のIssueが立てられたのは、2018年4月でした。
私はまだ入社しておらず、Androidエンジニアは照井さんだけでした。ちょうど、Androidのフルリファクタリングが進められていた時期ですね。
照井さん一人によって成し遂げられたフルリファクタリングについては、以下の記事で紹介しています。
その後2018年10月に私が入社し、その年末からCI/CD構築作業をスタートしました。当初の目的は、 「各環境に応じて「テスト → DeployGateへのアップロード」というのを1クリックでできるようにする」でした。APKのビルドはマシンパワーを使いますし、その間コードの変更などができません。
それをすべて自動化するだけでも、大変な作業効率化に繋がると考えてのことでした。
最初に想定していたゴールはこういった形です。（実際のIssueのスクリーンショット）
この時点で、Unit Testはいくつか存在していましたが、UI Testはまったく書いていませんでした。このため、第1弾では UI Testの実行は省略しています。
また、検討を進めるなかで「DeployGateへのAPK自動アップロードはしない」という結論に至りました。前述の通り、アプリをリリースするには、STG環境でクライアントに確認していただく必要があります。ブランチのマージを契機にビルドしたAPKを自動的にDeployGateへ配布すると、クライアントには予告なくアプリを更新してしまうことになります。それは避けたほうがよいだろうと考えてのことでした。
このため、APKのビルドは 「ルールに沿った名前のタグがつけられた際」に実行しているのです。
タグ名の命名規則は、さるぼぼコイン：sarubobo-* 、アクアコイン： aqua-* としています。
ハイフンの後ろは、DeployGateにアップする際のVersionを指定する運用にしています。
第１弾での対応をまとめます。
● ローカル環境での静的解析の自動化
● push/merge契機でのUnit Testの自動化
● タグ打ち契機でのAPKビルドの自動化
UI Testの自動化は、まずテストを書くところからスタートしました。
それまでUI Testというものを一度も書いたことがなく、またこの時点で画面数が相当な量になっていたため、この「テストを書く」というタスクにかなりの時間を割いています。
実装開始が2019年6月中旬、終了が2019年8月頭なので、ざっと2ヶ月弱でしょうか。これは結構つらい作業でした。
Issueにも、その片鱗が残されています。（混乱しているのが見て取れるコメント）
UI Testを実装するにあたっては、以下の記事を大変参考にさせていただきました。
これらの記事がなければ、途中で諦めていたと思います。深い感謝を捧げたいと思います。
Kyash Android で UIテストを導入した時の方針 - Konifar's WIP
RxJavaのアプリをEspressoでテストする簡単な方法 - Speaker Deck
UI Testの実行は、 Firebase Test Lab で行っています。
GitLab CIでUI Test用APK作成 -> Firebase Test Labへ投げる、の流れで処理しています。
ハマりポイントとしては、サービスアカウントの設定です。
Firebase Test Labでの実行には、適切な役割のサービスアカウントが必要になります。Firebase TestLab管理者という名前の、一見それらしきものがありますが、これだと権限エラーになります。
正しくは 編集者 です。（とても紛らわしい…）
そんなわけで、UI Testの実装に苦しんだり、サービスアカウントの罠にハマったりしながらも、第2弾の目標はなんとか達成することができました。
● UI Testの実装
● UI Testの自動化（Firebase Test Lab）
このように、第1弾／第2弾と段階を経て、CI/CD環境を構築しました。
DeployGateへの自動アップロードをしていないなど、ちょっとした制限はあるものの、静的解析やテストの自動化・APKのビルド対応によって、開発効率はぐんと上がったのではないかと思います。
とはいえ、APKの作成時は時間が掛かってしまっていたり、UI Test自体のメンテナンスが追いついていなかったりと、まだ課題はあります。
CI/CDのような、品質や効率に関わるタスクはどうしても機能開発に劣後してしまいがちですが、ないがしろにしてはいけないと思います。
今後も、最新の情報をキャッチアップしたり、日々変化する開発を取り巻く現状を見直したりしながら、よりよいCI/CDの形を模索していきたいです。
※各社の会社名、システム名、製品名などは、一般に各社の登録商標または商標です。
島本さん、ありがとうございました。
これからどう変化していくのか楽しみです。
現在、新型コロナウイルス感染症の影響に伴い、フィノバレーではリモートワークを継続して実施しています。
島本さんに、リモートワーク後に変化したことや新しい習慣について聞いたところ、「在宅勤務が始まって以来散歩を日課にしていますが、8月は暑くてなかなか大変でした。9月に入ってようやく涼しくなりましたし、ヘルスケア機能もリリースされたので、また頑張って歩こうと思います。」とのことでした。
まだまだ、暑い日が続いています。皆さんも体調にはくれぐれもお気を付けください。
今回もお付き合いいただき、ありがとうございました。
/assets/images/6626824/original/07ff581d-7477-4b87-be9f-2f044b0cb386?1619536238)
/assets/images/6626824/original/07ff581d-7477-4b87-be9f-2f044b0cb386?1619536238)
