はじめに
前回の記事では、条件に合うメンバーを新しいチャンネルにまとめて参加させるSQLを、読みやすく書き直しました。
この記事では、そのSQLを本番DBに対して手作業で実行している運用を、どう変えるかを考えます。
前回と同じく、業務の内容はサンプルの例に置き換えて説明します。社内チャットツールで新しいチャンネルを作ったときに、「ほぼすべてのチャンネルに参加している社員」をまとめて参加させる作業です。対象は、参加しているチャンネルが12個以上の有効なメンバーです。
結論として、Django の管理画面にアクションを追加する方法をチームに提案します。実装前の検討段階の内容です。
環境は次のとおりです。
- アプリは Django
- 本番は Amazon ECS（AWS Fargate）
- DB は Amazon Aurora MySQL
- リポジトリは GitHub の Team プランのプライベートリポジトリ
- Django の管理画面のユーザーは、個人ごとに発行している
今の運用と課題
新しいチャンネルを作ると、依頼を受けたエンジニアが次の手順で作業しています。
- チャンネル名から、新しいチャンネルのIDを調べる
- 本番DBに接続し、確認用のSQLで対象の人数を数える
- 人数と登録用のSQLを、ほかのメンバーにレビューしてもらう
- 登録用のSQLを実行する
- 確認用のSQLをもう一度実行し、対象が0人になったことを確かめる
- 実行したSQLと人数を、Slack上に記録に残す
確認用と登録用のSQLは、チャンネルIDを手で書き換えてから実行します。書き換える箇所は、確認用のSQLに2か所、登録用のSQLに3か所あります。
この運用には、次の課題があると考えます。
- IDの書き換えを間違えると、対象のメンバー全員が別のチャンネルに参加してしまう
- 確認用と登録用のSQLを取り違えると、確認しないまま登録される
- 誰がいつ実行したかを、手作業で記録している
考えた方法
どの方法も、対象を選んで登録する処理をSQLの手作業からアプリのコードに移す点は同じです。コードにすれば、レビューとテストは1度で済み、作業のたびにSQLを書き換える必要がなくなります。
その処理を動かす方法として、次の3つを比べました。
管理コマンド＋GitHub Actions
処理を Django の管理コマンドにし、GitHub Actions から手動で実行します。
別の人の承認を必須にする GitHub の機能（Environment の required reviewers）は、Team プランのプライベートリポジトリでは使えません。
Slack アプリ
チームで使っている Slack のスラッシュコマンドからモーダルを開き、メンバーを参加させる新しいチャンネルを選びます。アプリが人数などの確認結果を Slack に投稿し、ほかのメンバーがそのメッセージのボタンを押したときだけ登録されます。
その分、Slack からのリクエストを受け取るエンドポイントや DB への経路など、作るものが多くなります。
管理画面のアクション
Django の管理画面でチャンネルを選んでアクションを実行し、確認ページで人数を確かめてから登録します。AWS や GitHub の設定は必要ありません。
一方で、レビューを受けずに「参加させる」を押すこともできてしまいます。
比較と提案
3つの方法を、新しく作るもの、ミスの防ぎやすさ、別の人のレビュー、実行の記録の観点で比べました。
| 管理コマンド＋Actions | Slack アプリ | 管理画面のアクション | |
|---|---|---|---|
| 新しく作るもの | 管理コマンド、ワークフロー、この作業用の AWS の権限（IAM ロール） | Slack アプリ、モーダルとメッセージの処理、エンドポイント、DB への経路 | アクションと確認ページ |
| IDの入力ミス | 入力するので、照合が必要 | モーダルで選ぶので入力しない | 一覧から選ぶので入力しない |
| 確認と登録の取り違え | 人数を入力させて照合すれば防げる | 確認結果のボタンからしか登録できない | 確認ページからしか登録できない |
| 別の人のレビュー | ルールで守る（レビューなしでも実行できる） | ほかのメンバーが許可しないと登録されない仕組みにできる | ルールで守る（レビューなしでも押せる） |
| 実行の記録 | Actions の実行履歴（ログの保存期間は既定で90日） | Slack のメッセージ | 管理画面の変更履歴（DB に残る） |
この比較から、管理画面のアクションを提案します。理由は次の3つです。
- IDを入力せずに一覧から選べて、確認ページを通らないと登録できない
- 新しく作るものが最も少なく、AWS と GitHub の設定を変えない
- 誰がいつ実行したかが、変更履歴に残る
提案する管理画面のアクション
今の作業手順と比べると、次のように変わります。
人が操作するのは3つの手順になり、記録は自動で行います。レビューを残すかどうかは、後で述べるとおりチームで相談します。
操作の流れは次のとおりです。画像は画面のイメージです。
- チャンネル一覧で新しいチャンネルを1件選び、「対象のメンバーを一括で参加させる」を実行する
- 確認ページに、チャンネル名と対象の人数が表示される
- チャンネル名と人数が依頼どおりかを確かめて、「参加させる」を押す
- 登録した内容が、そのチャンネルの変更履歴に残る
チャンネル一覧で新しいチャンネルを選び、アクションを実行する画面です。
チャンネル名と対象の人数を表示する、確認ページです。
ミスを防ぐ仕組み
確認ページを通らないと登録できないようにする
アクションを実行しても、確認ページを開くだけにします。登録は確認ページの「参加させる」からしか行えないので、確認と登録を取り違えることがなくなります。
使える人を絞る
特定のグループの人だけにアクションを表示するようにします。確認ページでも同じ判定をして、URLを直接開いても使えないようにします。
失敗したらすべて取り消す
登録を1つのトランザクションにまとめ、1人分でも登録に失敗したら、その回の登録をすべて取り消します。一部のメンバーだけが参加した状態にはなりません。
誰がいつ実行したかを残す
登録した内容を、そのチャンネルの変更履歴に記録します。管理画面のユーザーは個人ごとなので、誰がいつ何人を参加させたかを、手作業なしで確認できます。
実行した人と日時、参加させた人数が記録された、チャンネルの変更履歴の画面です。
ここまでの4つの仕組みは、Django の管理画面の標準機能（アクション、独自のページの追加、権限の判定、変更履歴）を組み合わせて作れる見込みです。
レビューは必要か
今の運用でレビューが必要なのは、SQLを毎回手で書き換えるため、IDの書き間違いや、確認用と登録用の取り違えが起こる可能性があるからです。管理画面のアクションではこの2つが起きないので、毎回のレビューはなくてもよいと考えています。
残るのは、チャンネルを選び間違えたときと、人数がいつもと大きく違うときです。どちらも確認ページにチャンネル名と人数が出るので、実行する本人が確かめられます。
気になるのは、間違えて登録したときの取り消しは手作業になります。レビューを残すかどうかは、この手間も含めてチームで相談します。
導入にあたって考えておくこと
- 間違えて登録したときは、手作業のSQLで取り消す（そのため、追加したメンバーのIDを登録の処理でログに出力しておく）
- 管理画面から本番データを一括で変更できるようになるため、このアクションを誰が使えるようにするかを考える必要がある（たとえば、専用のグループを作り、使う人だけを入れるなど）
おわりに
この作業は毎日行うものではないため、作るのに手間をかけすぎず、手作業のミスは防げる方法を選びたいと考えていました。そこで、Django の管理画面のアクションを選びました。
チームに提案するときは、次の点を相談して決めたいです。
- アクションを、依頼した PM が自分で使えるようにするか、これまでどおりエンジニアだけが使うか
- 確認ページのレビューを残すか、残すならどこで誰が行うか
提案が採用されて実装まで進んだら、結果を記事にできたらいいなと思います！
参考