- AWS Lambda(API)
- AWS API Gateway(API)
- Cloud Functions(API)
- (WebアプリはローカルでOK)
- (モバイルアプリはローカルでOK)
開発用のLambda関数名にはprefixとしてtest_
をつける。ソースコード自体は開発用と本番用で分けない。デプロイ時に関数名と一部の定数の値を変える。
- コード内で、Firestoreの認証情報(common.goのSecretManagerSecretNameという定数)が開発用のプロジェクトのものか確認する
- コード内で、ProjectIdが開発用のプロジェクトのものか確認する
- AWS CLIで関数をデプロイする(
test_
をつける)
websocketと普通のhttpの2種類。 開発用とリリース用で別々にAPIを用意する(ステージで分けてもいいけどその都度関数を書き換えていくのが面倒なので)。 websocketのほうは自動デプロイができないため、統合の切り替え・追加・削除といったAPI Gateway側での変更を行った場合には毎度手動でデプロイする必要がある。 httpのほうは$defaultというステージで自動デプロイをオンにしてあるため、手動デプロイは必要ない。 websocketもhttpも、統合するLambda関数を更新しただけであればデプロイは必要ない。
- websocketは開発用のAPIで手動でデプロイする
- クライアント側で正しいurlになっているか確認する
FirebaseAuthNewUserListener関数だけはAWSではなくCloud Functionsにデプロイする。
- コンパイルが通るように、リポジトリのcloud_functionsディレクトリに行き、aws_lambdaディレクトリからコードを手動でマージする。package名はgo_apiのはず。LambdaだとFirestoreの認証をSecret Managerから取得する処理があるが、Cloud Functionsなら必要ないのでその部分のコードはマージしない。
- gcloud CLIでprojectが開発用のプロジェクトになっていることを確認する
- 関数をデプロイする
- AWS Lambda(API)
- AWS API Gateway(API)
- Cloud Functions(API)
- Firebase Hosting(Webアプリ)
- Google Play Store(モバイルアプリ)
本番用のLambda関数にはtest_
がついてない名前の関数を用意する。
- コード内で、Firestoreの認証情報を本番用のプロジェクトのものに切り替える
- コード内で、ProjectIdを本番用のプロジェクトのものに切り替える
- websocketは本番用のAPIで手動デプロイする。
- クライアント側でAPIのurlを本番用に書き換える
FirebaseAuthNewUserListener関数だけはAWSではなくCloud Functionsにデプロイする。
- コンパイルが通るように、リポジトリのcloud_functionsディレクトリに行き、aws_lambdaディレクトリからコードを手動でマージする。package名はgo_apiのはず。LambdaだとFirestoreの認証をSecret Managerから取得する処理があるが、Cloud Functionsなら必要ないのでその部分のコードはマージしない。
- gcloud CLIでprojectが本番用のプロジェクトになっていることを確認する
- 関数をデプロイする
- firebase CLIでプロジェクトが本番用のものであることを確認する
firebase deploy
でデプロイする
次のことに注意してリリースする。
- アプリバージョン
- Firebase Authの認証が有効なものか(google-service.jsonみたいなの。SHA-1、SHA-256を登録するやつ)