FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
最小DB基盤と手動migration workflowを実装する
将来の機能を先取りせず、必要なdatabase objectを段階追加できるproduction境界を作る
目的
後続機能がdatabase objectを積み上げられるproduction基盤は必要だったが、将来を予測したtableやRPCを初期段階で固定すべきではなかった。
初期schemaと権限だけを標準migration履歴で管理し、人間が確認して適用する最小経路が必要だった。
実装
初期migrationはapi、private、app、codex、editorialの5 schema、初期ACL、default-denyだけを作成する。table、view、RPC、trigger、index、seed、RLS、製品dataは作らず、必要になった機能の作業単位で設計とtestを追加する方針にした。
- Data APIへ公開するschemaをfacadeの
apiだけにする。 - client roleには
apiの利用だけを許可し、domain schemaの直接利用とobject作成を拒否する。 - 将来作られるtable、sequence、functionへclient権限が自動付与されないdefault privilegeを設定する。
- 標準migration履歴を正本とし、適用前後に履歴とdry runを確認する手動workflowを用意する。
- 後続機能はmigration、test、検証script、local専用dummy fixtureを同じ作業単位で追加する。
将来を想定して作ったlocal prototypeは正本から外し、read-onlyな参考へ退避した。恒久testはschema、ACL、default privilege、公開API境界のように、後続objectが増えても変わらない条件へ絞った。
図を描画しています…
確認したこと
確認結果
fresh reset、1つのpgTAP fileに含まれる10 assertion、5 schemaのdatabase lintが通った。
Data APIはapiだけを公開し、non-RPC pathは0件だった。
migration workflowの標準的なlink、履歴確認、dry run、apply、再確認の順序が検証された。
全体build、型検査、test、secret scan、90件の要件と50件の受入条件の監査、live参照検証が通った。
productionでは5 schema、ACL、default privilege、apiだけのData API公開を人間が確認した。製品table、Auth owner、agent registryはまだ作成していなかった。
完了とした根拠
最小の5 schemaとdefault-denyを標準migrationで定義し、手動workflowからproductionへ適用したうえで、local testと人間によるschema・ACL・Data API境界確認が揃ったことをもって完了とした。