はじめに
この記事はMIXI DEVELOPERS Advent Calendar 2022 の22日の記事です。
この記事はなに？
昨年からFlutterでアプリ(iOS/Android)開発をはじめ、今年の頭に初めてアプリをリリースしました！
リリースする際に考えたブランチ戦略、デプロイ方法と仕組みについてまとめてました！
この記事で紹介すること
- ブランチ戦略について
- デプロイ方法と仕組みについて
上記について紹介します！
環境
今回の記事は以下の環境、ツールを使用しています。
- MacOS: monterey 12.6 2
- Flutter: 3.0.2
- Fastlane: 2.190.0
- GitHub
- DeployGate
- Bitrise
ブランチ戦略について
まずはアプリをリリースするまでのブランチ戦略についてご紹介していきます！
具体的なリリース手順
以下の図でリリース作業を進めています。それぞれ解説していきます！
各ブランチの役割
- main: 新しい機能を作成するための起点となるブランチ
- feature: 機能ごとに作成するブランチ。機能が完成したらmainブランチに対してPRを作成する。このタイミングでDeployGateにビルドが作成されるで、QAさんに確認してもらう
- work: 作業ごとに各人が作成するブランチ。作業が完了したらfeatureブランチに対してPRを作成する
- bumpup: mainブランチの内容をリリースする際にバージョンのアップグレードをおこなう
- staging: 各機能が正常に動作しているか最終確認をおこなう
- production: このブランチ入った機能をもとにリリース作業をおこなう
こちらの手順で作業を進めています！
デプロイ方法と仕組みについて
ここからは上記のブランチ戦略を進めるために使っているデプロイ方法と仕組みについて解説していきます！
デプロイ方法について
デプロイ方法としては2つ用意しており
- 特定のブランチにPR作成、PushをトリガーにBitrise経由でデプロイ
- 手元から手動で特定のlaneを実行してデプロイ
を用意しています。
どちらもデプロイツールとしてFastlaneを使用しており、Bitrise内でFastlaneを実行するか、手元の環境でFastlaneを実行するかだけの違いになります。
なぜ手元からもデプロイ出来るようにしたのか？
基本的にはBitrise経由でデプロイを行うのですが、以下の理由から手元からデプロイする手段を残しておきました。
- Bitriseが万が一ダウンしてもリリースする手段を残しておきたかった
- Bitriseにベンダーロックインな状態にしたくなかった
上記2点が大きな理由となります。Fastlaneにデプロイ作業に全て任せる状態にしておけば、Bitriseから低コストで他のサービスに乗り換えることが出来る状態にしました。
デプロイの仕組み
上記を踏まえた上でデプロイの仕組みは以下の図のようにしました。
Bitrise経由でのテスト実施からの各環境へのアップロードを基本としつつ、手元の環境でもFastlaneを動かせる状態としました。
複数のlaneを作成して、ブランチの作成、プッシュをトリガーにDeployGate、各プラットフォームの内部テストに自動的にデプロイされるようになっています。
終わりに
今回ブランチ戦略からデプロイの仕組みまでまるっと作成しました。
初めて触るツールや、アプリならではの証明書周りで苦戦しつつ、なんとかここまで出来たのでとても良い経験となりました！
まだまだ改善の余地もあると思うので、今後も引き続き改善していければと考えています！！