[第42回] 運用DB作業に二段階承認を付ける

開発がSQLと条件を確認し、運用が対象と目的を見て最終承認するなど、一人では完結しない場合がある。

今回はQueryPieでその順序を作り、 別担当者によるSQL Request二段階承認の後に実行することを試した。SQLは注文1件の状態・金額参照だ。

開発確認と運用承認を二段階にする

管理者の General → Workflow Management → Approval RulesでEP42 - Two-Step SQL Approvalを作り、SQL Requestを指定した。

一次承認者は Demo Approverとして開発確認を担う。Add Stepで二次を作り運用担当の Demo Auditorを入れた。

両段階とも事前指定の Select Assignee(s) / Group(s)を使い、実行者は開発者、自己承認Offとした。申請時に選ぶのでなく所定担当へ順に送れる。

提出前から順序が見える

規則を選ぶと三人が順に表示され、誰が先に確認し最後に実行するか申請時から分かった。

対象接続は Two-Step Approval Labで、41001のSELECTとし、理由にも開発確認後の運用承認と1件参照を記載した。

SQL・DB・理由を一つにまとめ、別送を減らせた。タイトルは 「第42回の注文参照 — 開発確認後に運用承認」とした。

一次だけでは実行へ進まない

Demo Approverが番号条件とテーブルを確認し、一次意見を残して承認した。

申請者側では一次が緑、次の二次が黄、実行者は待機だった。

一覧でも明確で、 Approval Status In Progress、Execution Status Pendingだった。実行者のExecutions → To Doにはまだなかった。

二人の名前を置くだけでなく、次の承認がなければ実行へ進まない点がよかった。

二次まで完了して実行の順になる

Demo Auditorが接続・範囲・理由を見て最終意見を残した。同じSQLをそれぞれの役割で確認する流れだ。

最終承認後、開発者の Executions → To Doへ表示された。承認者二人が緑、実行者が黄となり、 Execute も利用可能だった。

承認SQLを実行すると、結果は 1 Rows selected.でDoneへ移った。同じ流れで誰の順番か追いやすかった。

承認二回と実行が個別に残る

最後に管理者の Workflow Logsでタイトルを探すと提出・一次・二次・実行の4件があった。

Remaining Stepsは申請後の Approval 1から一次後の Approval 2、最終後の Execution、実行後の Doneへ進み、各担当者と時刻も残った。

Query Auditも開発者のSQL Request成功で、承認履歴と実DB操作をつなげて確認できた。

よかったのは、 会社の確認順序を実際の作業手順へ移せることだ。開発・運用の確認後に実行へ渡し、進捗と履歴も残るので複数担当の管理に役立ちそうだ。

QueryPie Community 11.6.7とMySQL 8.0.42で実習担当者・注文を使った。

参考： Approval Rules · SQL Requestの申請 · Workflow Logs