プッシュ通知はメールと似たようなシステムになっています。送信処理を行ってしまったら後戻りはできません。時々、件名や本文にテンプレート(社名など)がそのままになっているメールが届いてしまったり、逆に送信してしまったりして対応に追われたことはないでしょうか。
プッシュ通知でのミス送信は、非常に嫌われます。それこそミスメール以上に嫌われるのではないでしょうか。そうしたミスを防ぐためにも、テスト配信を行う仕組みが必要です。今回はテスト配信を実現する二つの運用方法を紹介します。
NCMBでは一つのアプリに一つの証明書のみ
まず前提条件として、NCMBでは一つのアプリに一つの証明書やプロジェクトキーしか指定できません。そのため、一つのアプリの中にテスト用と本番運用用のデバイストークンを混ぜることができません。正確には混ぜられるのですが、見分けを付けることができず、配信時にエラーになる原因となります。エラーが多いと、配信を途中で中断してしまうことにもなります。
そのため、取り得る方法は二つあります。
- アプリを2つに分け、テストと本番で証明書を分ける
- 共通の証明書を使う場合には本番運用の証明書を使う
アプリ(証明書)を分ける場合
アプリ(証明書)を分ける場合の利点としては、間違って本番のユーザに対して配信してしまう可能性が少ないと言うことでしょう。管理画面がはっきりと分かれているので、気付きやすいというメリットがあります。
ただし、たとえば「プッシュ通知をタップした際にmBaaSからデータを取得して処理分岐を行う」といった仕組みを考えた場合、テスト用のアプリにも同じデータを登録しなければなりません。プッシュ通知以外の運用でテスト用アプリを使わない場合、本番環境とのデータの乖離が発生する可能性があります。あくまでもプッシュ通知を試すだけと割りきる方が良いでしょう。
アプリを分ける場合、お勧めなのは管理画面のテーマ機能を使ってカラーリングを区別することです。例えばテスト用は緑、本番用は赤と色分けしておけば、テスト配信を行う際にも認識しやすくなります。
アプリを分けると、アプリ単位での共有ができます。プッシュ通知の担当者を決める際に、本番環境での実行は上長のみとしておくことで、担当者は常にテスト環境にしかログインできないようにするといった制御も可能です。
同じ証明書を使う場合
同じ証明書を使う場合には管理画面は共通になります。本番ユーザのデバイストークンも含まれていますので注意が必要です。この場合、テスト用のデバイストークンだけ例えばtestというカラムを作ってtrueを設定しておきます。そして、常にこの条件を指定して配信を行います。
メリットは証明書を分けた場合と違って、データが本番環境そのものであり、データの状態に応じたメッセージ振り分けなども確認しやすいということです。プッシュ通知を開いた後の表示も、本番環境のデータを使った方が本番さながらになります。
証明書が一つだけなので、更新の手間が一度で済むのもメリットでしょう。二つに分ける場合に比べて運用負荷は小さくて済むはずです。
まとめ
どちらの運用を選ぶにしても一長一短はあります。よりミスの少ない運用を目指すのか、運用負荷の小さい方を取るのかはアプリの種類や運用体制によっても異なるでしょう。ぜひ皆さんのアプリ運用時に参考にしてください。
次はこちら: