多くのチームは DevOps を主張しながら、データベースの変更は誰かのラップトップから手動でデプロイしている。その矛盾こそ、この Azure SQL ガイダンスが修正するものである。SQL プロジェクトと Azure DevOps パイプラインは、実際の本番ワークフローに十分な決定論的、監査可能、セキュアなデータベースデリバリーを実現する。
オリジナルソース: https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/
このアプローチの最も強力な部分は YAML 構文ではなく、規律の順序である: 最初にビルド、次に公開、そして最小特権とパスワードレス ID でデプロイパスをセキュアにする。dotnet build で .sqlproj をビルドすることで、ターゲットプラットフォームとの互換性を早期に検証し、環境間でプロモート可能な DACPAC アーティファクトを生成する。
私の見解は明確である:スキーマが CI でビルドされていないなら、データベース品質プロセスはほとんど希望にすぎない。SSMS や VS Code でのローカル成功はリリースの保証ではない。
デプロイ設計もまた、新鮮なほど実用的である。Entra ID に紐づいたサービス接続を使用し、スキーマとデータ比較のためにスコープ付きデータベースロールを付与し、ランナー IP の一時的なファイアウォール開放を確実なクリーンアップ付きで自動化する。これは、侵害レビューがすべてを再考することを強制するまでチームがスキップする種類の運用衛生である。
すぐに適用すべき実践的推奨
- ビルドとデプロイのパイプラインを分割する。 ビルドはブランチ変更時に実行し、迅速に失敗するべきである。デプロイは環境固有でポリシーゲート付きにするべきである。
- ターゲット接続文字列とインフラメタデータをセキュアなパイプライン変数に格納し、ロール割り当てのガバナンスレビューを定期的に実施する。
- SqlPackage のバージョンを CI で明示的に固定し、予期しない動作変更を避ける。
早期に過剰な特権を付与しないこと。 db_ddladmin、db_datareader、db_datawriter から始めることは、「とりあえず動かすため」にすべてのパイプライン主体に db_owner を渡すよりも優れたベースラインである。具体的なデプロイ要件が必要であることを証明した場合にのみ権限を昇格させる。
もうひとつの重要なポイントはポータビリティである。SQL プロジェクトは .NET SDK ツールチェーン上で動作するため、このパターンは Azure DevOps 限定ではない。同じ基礎は GitHub Actions や他のオーケストレーターにも適用可能であり、このガイダンスは戦略的であって、プラットフォームにロックされていない。
結論
組織が依然としてスキーマデリバリーをアプリ CI/CD の外部にある特別なプロセスとして扱っているなら、これが移行のブループリントである。英雄的なプラットフォームエンジニアリングは必要ない。必要なのは一貫性、アイデンティティファーストのセキュリティ、そしてアドホックな特権パスを通じてデータベース変更を出荷するのをやめる意志である。
これを実行するチームはより速く出荷でき、ロールバックも少なくなる。遅らせるチームは、手動のデータプレーンデプロイという隠れた税金を払い続けることになる。
