とことんDevOps | 日本仮想化技術が提供するDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けするとことんDevOpsでは、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果など、DevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、アジャイル開発、コンテナ開発など

開催予定の勉強会

各種SNSのフォローもよろしくお願いいたします。

イベントレポート 第6回とことんDevOps勉強会「開発からアプリストアまで一気に自動化!モバイルアプリのCI/CD徹底解説」

9月29日に開催された第6回とことんDevOps勉強会のレポートです。

今回は日本仮想化技術の石本から「開発からアプリストアまで一気に自動化!モバイルアプリのCI/CD徹底解説」と題してお話しさせていただきました。モバイルアプリのCI/CDをGitHub Actionsを使って実現した際の検証結果をもとに、ストアにアップロードするまでのお話しをさせていただきました。Flutterを使ったクロスプラットフォームのモバイルアプリをFastlaneを使ってiPhoneおよびAndroidのストアにアップロードする仕組みを解説しています。

 

振り返りも兼ねて当日の配信の様子をYoutubeでアーカイブしていますので、是非ご覧ください。当日参加できなかった方も、これを機会にとことんDevOps勉強会に興味を持っていただければと思います。また、当日いただいたQ&Aに関してもこちらのブログでまとめていますので、ご覧ください。

なお、情報量が多かったため、本編では後半を駆け足で説明していますが、Q&Aコーナー内で後半部分を改めて振り返りを行なっています。YouTube動画では無編集で公開しているんため、後半部分はQ&Aコーナーも含めてご覧いただければと思います。

セミナー動画 - YouTube Liveアーカイブ

www.youtube.com

発表資料 - Speaker Deck

speakerdeck.com

Q&Aまとめ

Q : クロスプラットフォームのモバイル開発ではFlutterが主流なのでしょうか?

 

Googleによって開発された比較的新しい技術で、今ちょうど盛り上がっている感じがしています。React Nativeのポジションを狙っているのではないかと思っています。

 

Q: クロスプラットフォームの開発技術の中でFlutterが得意とする分野はどのような分野でしょうか?

 

ネイティブアプリとして、スマートホンのみではなく、デスクトップなどにも今後力を入れていくそうなので、全方位的に発展していくのではないかと思っています。

 

Q : 以前、XamarinやAndroid Emulatorなど使った際には 少し操作が重たく感じたのですが、 開発PCのスペック(CPU・メモリなど)って どれくらいあるといいですか?

 

Macbook Proを使っている経験から言うと、32GB以上のメモリを積んでいればストレスなく実行できると感じています。16GBではやはり動作が重くなってストレスを感じました。

 

Q : 実行される場所が微妙だったのですが、例えばAndroidのアプリ公開だったらAABを生成するところまではローカルですか?

 

ビルドに関してはGitHub Actionsが提供するクラウド上のランナーにて実行されます。GitHub Actionsからコマンドでビルドを実行し、それがクラウド上で実行されるイメージです。GitHubにコードをプッシュするところまでがローカルでの作業で、それ以降はCI/CDの方でクラウド上で実行すると言う形になります。

 

Q : 特に複数のエンジニアで共同作業をしている場合にはストアにデプロイする場合のメジャーバージョン、マイナーバージョン、内部バージョン(毎回アップデートが必要)などの管理も面倒な感じがするのですが、CIの中でそれを管理するのにはどのような手法を使っていますか?

 

ビルドのバージョンに関しては、ストア上のバージョンを正として、それに対して矛盾がないかのチェックを行うのが良いと思います。その前提として、バージョニングルールを決めておく必要があるかと思います。

 

Q : ノーコードによるモバイルアプリ開発って、どうなんでしょう?

 

短期的に作り捨てて良いようなアプリであればノーコードでも良いと思います。ただし、業務フローなど複雑な仕組みがあり、長期的にメンテナンスしていくような場合は、最終的に問題が発生してもエンジニアがメンテできないという可能性があるので、あまりおすすめはできません。

 

また、参加者の方からセッション中に残ったGradleによる署名の手順に関してコメントを頂けました。

質問ではないですが、先ほどのgradleでの署名の件、Androidアプリ(APK)で使われていた古い署名方式ではアプリ署名は手元で行ってそれをストアにアップロードしていました。そのための署名の処理手順(キーストアファイル名やパスフレーズ、エイリアスなど)がbuild.gradleに書かれています。

AABで採用された新しい署名方式ではアプリがストアにアップロードされてからGoogle側で自動的にアプリに署名されるようになったのですが、 アップロードされたアプリが正規のデベロッパーによってアップロードされていることを証明するために「アップロード署名」を手元で行なうというステップが増えました。

「アップロード署名」にはAndroidアプリ(APK)で使われていた古い署名方式でのアプリ署名がそのまま流用されてるので新しいアプリ署名用のbuild.gradleにも手元でのアプリ署名の処理がそのまま残っています。